[Mageia-dev] Java-Policy first draft published

Wed Jan 12 17:24:09 CET 2011

Farfouille wrote:
+> Hi
+>
+> I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy
+>
+> Corrections and comments are welcome.
+>   
+
+The bit about pre-packaged JARs may cause trouble.  In theory, it's
+great, but many applications depend upon certain versions of their
+utility JARs, and can't all run with the latest versions.  Any such app
+would have a Requires for its specific version, which would prevent the
+utility JAR from being updated with a newer version for other apps. 
+This is why EJB allows EJB apps to include their own specific versions
+of utility JARs, which are visible to them but not to other apps or the
+container itself, and also why Maven uses versioned artifacts.
+
+An extreme example of such an app is NetBeans, which includes its own
+versions of Ant and Maven.
+
+Also, for such apps, upstream developers may refuse to investigate
+issues unless the shipped versions of supplemental JARs are being used.
+
+> As I have never used maven, a deep reread is required
+>
+>
+>   
+
+Maven POMs allow the packager to specify required other objects
+("artifacts") not only for building the package but for execution as
+well.  There are central Maven repositories which contain versioned
+artifacts for commonly-used projects, e.g. JUnit, and many companies
+have site-wide repositories of their own.  Finally, every user of Maven
+has a personal repository located in $HOME/.m2, which is why the policy
+has code for creating this directory.
+
+Repositories are seached for needed artifacts from the most local (the
+user's personal repository) to the most remote (the central Maven
+repositories) as directed by a settings.xml file in the user's .m2
+directory or <repositories> tags in the individual pom.xml files.  The
+general intent is to obtain artifacts from the "closest" repository. 
+Company repositories are not just the central location for
+company-specific artifacts, but also a local cache for central Maven
+repository artifacts.
+
+>From the policy, it looks like the personal repository for the ID under
+which RPM builds the package is wiped clean for every package, and thus
+every needed artifact will be downloaded from the remote repositories
+for every build.  If that's the case, it's an awful waste of bandwidth,
+since many of these artifacts are used for every Maven project.
+
+We might want to consider having a central repository for each system,
+which would be one level above the individual users' personal
+repositories, and would be used before more remote repositories.  There
+is no harm to allowing artifacts to accumulate there, since all
+artifacts are versioned.  Cleanup might be possible through filetriggers
+if a tool identified all dependent artifacts for each installed Maven
+package, and deleted ones no longer used by anything installed.  If
+there were such a repository, say under /var, then it should be used for
+builds rather than an individual repository tied to the RPM userid.
+
+There's also the issue of allowing company or site repositories to be
+used if they exist.  For packages installed during system installation,
+there would be no way for a sysadmin to specify local repositories
+unless the install were modified to allow it, but few if any Java
+packages (much less Maven ones) are installed at that time.  For later
+package installs, perhaps a dynamic settings.xml could be created for
+the build using XML fragments in something like an
+/etc/maven/repositories.d with the same sort of numeric prefix
+preference that chkconfig uses to establish precedence.
+
+Finally, there's the issue of using repository artifacts on the system
+in the execution-time CLASSPATHs for the Maven applications.  Maven has
+a plugin which will build a single huge JAR containing an application's
+classes as well as classes from every JAR artifact on which it depends,
+and many docs recommend this as the way to distribute an application,
+but it consumes quite a bit of space as every app is carrying its own
+copy of every supplemental utility class it needs when it could probably
+find the identical classes in the versioned artifacts in a system
+repository.  This ties in to the build-classpath and
+build-jar-repository capabilities for non-Maven apps.
+
+By the way, the policy should probably contain full usage instructions
+for build-classpath and build-jar-repository as well as a description of
+the uses to which they are put.
+
+Good Work !
+
+
+
+