Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!
On Fri, Nov 09, 2001 at 12:29:44AM -0800, Kevin A. Burton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Adam Heath <email@example.com> writes:
> > > This is a practice that is unfortunately common in the Java world.
> > Common does not make it right.
> but it doesn't make it harder to *make* it right.
> > > Can I debian package require a specific version of another package?
> > >
> > > Specifically if I have a package foo can it require *only* libbar-1.1.3.deb ???
> > Certainly. It's what I'm doing for the jboss package.
> And what if foo requires libbar-1.1.3 which is incompatible with the fictional
> libbar-1.1.0 that jboss requires?
> How do you install both on the same system... Do you compute the CLASSPATH in a
> different manner for each application?
Yes that is what you have to do. Libbar-1.1.1 needs to be a package with
that name so an upgrade does not introduce conflicts. I think the new
proposed java policy adresses this quite good.
> > > 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.
> > There is no integration whatsoever with anything not java. If you have a
> > project, that has non-java elements, you are left all by yourself, when
> > integrating them.
> > Additionally, ears are prime example of java packaging gone wrong.
> Are you saying that .WAR files are also incorrect?
Yes they are most probably incorrect.
> Just because it isn't the UNIX approach doesn't make it incorrect.
> I have an Open Mind (TM) on the subject so I am listening... Explain why the
> Servlet WAR spec is incorrect and how it could be done better. (Specifically
> WRT the WEB-INF/lib approach).
Wars are not needed if you have deb packages. Why have a packaging system
(and a very bad one not allowing symlinks) inside an other packaging system?
You can use simple directories instead of the war files. :)
> > > > Lots of 'external' jars are not redistributable. You can't even have them
> > > > in the source package.
> > >
> > > This is a separate issue for debian-legal.
> > It's not a separate issue. We still are not allowed to distribute these jars,
> > in any form.
> My point was that if there are *existing* packages which have non-free .jars
> this is VERY important to correct.
> > > I seriously hope that we don't have packages with non-free libs. If this
> > > happens it would be a big issue :(
> > It already is an issue. Look for mail.jar and activation.jar. Those are SCSL
> > from sun. Bad mojo.
> ouch.. this needs to be corrected ASAP!
I know that some of my packages (read cocoon and cocoon2 distributes
non self-compiled jars, just copied from the source tree). This is because
I do not have the time to create about 15-20 new debs myself. I should
probably file a lot of RFP:s but I have not had the time. :)
I hope you do not mind too much.
> - --
> Kevin A. Burton ( firstname.lastname@example.org, email@example.com, firstname.lastname@example.org )
> Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - email@example.com, Web - http://relativity.yi.org/
> To fight and conquer in all your battles is not supreme excellence; supreme
> excellence consists in breaking the enemy's resistance without fighting.
> - Sun Tzu, 300 B.C.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
> -----END PGP SIGNATURE-----
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
--------------------- Ola Lundqvist ---------------------------
/ firstname.lastname@example.org Björnkärrsgatan 5 A.11 \
| email@example.com 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /