[Mageia-dev] Java-Policy first draft published

[Frank Griffin]

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 !