Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!
[ Responding to an old message. Sorry. ]
On Fri, Nov 09, 2001 at 12:29:44AM -0800, Kevin A. Burton wrote:
> Adam Heath <doogie@debian.org> writes:
> > Someone else writes:
> > > Due to the WORA nature of Java applications, a lot of projects assume they
> > > are the only package management system in existence. For example a lot of
> > > the Jakarta projects ship with a whole bunch of .jars which are both
> > > incompatible across projects and in their own ./lib.
> >
> > This is one of the main flaws of java. It assumes it is the only thing
> > around, and nothing else exists.
>
> > Additionally, ears are prime example of java packaging gone wrong.
>
> Are you saying that .WAR files are also incorrect?
Yes, and I think Adam is absolutely right. Here is a simple example
of why WAR files are broken. Suppose you want you web application
to have command-line administrative tools, which is a pretty
reasonably idea. Not only can you not put them in the WAR file, but
if you distribute them separately, you have to also distribute
another copy of the libraries for it to use.
> Just because it isn't the UNIX approach doesn't make it incorrect.
The UNIX versus Java thing is mostly a smoke-screen. There are no
significant issues raised by Java that Debian hasn't already
addressed. For example, Debian C binaries could all be packaged
statically linked, or dynamically linked to package-private
libraries. This would be analogous to the Java practice of bundling
libraries. But we've decided it is usually better to centralize
libraries and require major version compatibility. Basically, I
think we should take our policy for C libraries, and adapt it for
Java with few modifications. It is mostly a matter of writing the
helper tools.
Upstream Java developers bundle all their dependencies because Sun
hasn't given them any alternatives, and that is understandable (on
the developers' part, not Sun's!). But this is Debian, and we have
standards and conventions for our packages, so we should do better.
This might cause some difficulty in building packages, and may
require educating upstream developers, but it will be worth it.
Andrew
Reply to: