[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!



On Thu, Nov 08, 2001 at 10:30:36PM -0800, Kevin A. Burton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Adam Heath <doogie@debian.org> writes:
> 
> > I have noticed that almost ALL packages include external .jars in their
> > internal lib directories.  This *MUST* stop.  Yesterday.  Last year.
> 
> Don't be so extreme... nothing is black and white.
> 
> This is a practice that is unfortunately common in the Java world.
> 
> To solve it...

.. as in, fish around in a project's lib/ directory, and ensure that
*every jar* in there is it's own .deb? Ouch.. that's a pretty large
overhead. There's no general way to determine the version of a jar, so
packaging them all would first require a long, painful identification
process. For instance, some projects use CVS snapshots of jars.
It would be *really* difficult to pinpoint a jar version when all you've
got to go on is a CVS log like "updated to latest jar from foo to fix
bug X".

In addition, changing the default jar location would break init scripts,
security policy files and custom classloaders. Tomcat illustrates all of
these issues (and the issue of non-redistributable jars). You might get
away by symlinking the jars to their expected locations, *if* you can be
sure that none of the jars have a "Class-Path:" entry in their manifest
(which would then be incorrect).

[..]
> Due to the WORA nature of Java applications, a lot of projects assume they are
> the only package management system in existence. 

And they're right, if you take into account that a cross-platform app
needs a cross-platform package management system. There is nothing like
that now, and Java projects will rightly continue to bundle jars until
there is.

> > I will be filing bugs on all java packages this weekend that do this.  I will
> > not exclude non-free packages either.  This is something that must stop, and
> > we must not allow upstreams to do so either.

Please understand the issues before doing so :) If you try to "not allow
upstreams to", you need to provide a realistic non-Debian-specific
alternative. Believe me, *nobody* likes jars in CVS, and if there were a
robust, general solution, people would adopt it. Here are two attempts I
am aware of:

  "JJAR is an acronym for Jakarta JAR Archive Repository, an attempt at
  making a CPAN service/infrastructure for the Java development
  community."
    http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/jjar/


  "Aleutia is the build and package management tool for the Enhydra
  platform.
  ...
  In its most common usage, Aleutia provides a tool called Atta  for
  downloading Enhydra components. This is most like a package management
  tool found on Linux systems, or the Perl CPAN suite of tools. The Atta
  tool provides a user with a list of available components for
  installation. The user then can specify which of these components, as
  well as what versions, are desired."
    http://aleutia.enhydra.org/software/documentation/backgroundInfo/projectScope.html


--Jeff



Reply to: