Packaging large Java software stacks ?

[Thierry Carrez]

Fellow developers,

It is difficult to integrate the large recent Java software stacks
(Glassfish, Geronimo...) in a Linux distribution in general. The key
reason is that most of those stacks require very precise versions of
libraries (JARs) to run and to build. They won't work with the latest
version of libraries as those might change APIs and/or key behavior.
Java developers are used to pick specific JAR versions and assemble the
exact needed stack, they don't want to care about sharing their
dependencies with other packages, or about dependencies being upgraded.
Tools like Maven help them in this endeavor, and they rely very heavily
on this external code : dozens of those JARs are usually needed at
runtime, hundreds of those at build-time.

That makes most attempts to properly package large Java software in
Ubuntu to fail for two reasons.

(1) Need precisely-versioned artifacts
Those stacks need, as build dependencies and as runtime dependencies,
very precise versions of JARs. They won't build or run with a different
one. Using a more recent one might break functionality in a creative
way. A maven-based build will sometimes require 6 different versions of
the same JAR. In our packages, we usually offer only one version,
in corner cases one minor version for each major version. In some cases
the Java software will run/build with ours, in most cases it won't.

(2) Building entirely from source
Java "compilation" (in fact bytecoding) requires lots of JARs to be
present, because they are used to check all external method signatures.
Geronimo and Glassfish builds will require hundreds of them. Packaging
all those build dependencies from source is a huge work, and each of
those build dependencies, in turn, will require more. Combined with the
first problem, this makes packaging those stacks too much work for so
little to gain (they are usually easily installable by
downloading/unpacking the upstream tarball).

I am looking at ways to solve these issues, and would very much like to
hear ideas from our awesome community :)

Potential solutions to solve (1) include using a parallel delivery
mechanism for JARs, separated from the usual Ubuntu packages, something
that could hook into Maven repositories... or get ready to create a
separate package for each version of each JAR.

Potential solutions to solve (2) include evolving our build-from-source
policy to accept that JARs that would only be used as method-checking
media during Java compilation to be considered part of the source...

A solution to workaround both problems would be to avoid targeting our
built-from-source repositories for such Java software and pack them with
their binary dependencies (or as binary directly)...

Please let me know what you think of all this problem. I'm pretty sure
the Java world will one day gets its senses back and have a more
distribution-friendly dependency system, but we probably need a
solution until such day happens... or forget about such Java software
altogether.

-- 
Thierry Carrez
Ubuntu server team