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

Re: STOP INCLUDING EXTERNAL JARS IN YOUR JAVA PACKAGES!



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Heath <doogie@debian.org> writes:
<snip>

> > 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?

> > 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.

Agree.

> 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?

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).

> > > 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!

Kevin

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
             Location - San Francisco, CA, Cell - 415.595.9965
        Jabber - burtonator@jabber.org,  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

iD8DBQE765BmAwM6xb2dfE0RAmrCAJ9Q1vkjCvq4ySkWUhib47rZUkld5QCeNN1D
qm+CDaKcxthg/0b5jEmYmKI=
=FDQa
-----END PGP SIGNATURE-----



Reply to: