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

Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]



Le ven, 30/01/2004 à 09:38 -0500, David Walluck a écrit :
> Eric Bruneton wrote:

> >if you have precise instructions (or tutorials, or example projects) 
> >on how to organize Java projects, how to manage their dependencies, 
> >and how to build them, so that they can easily be packaged in rpm or 
> >debian packages, we can try to take them into account in the Fractal 
> >project (if you want, we can also include your rpm spec files in the 
> >CVS, and integrate the rpm building tasks in the build.xml files)
> >  
> >
> 
> Some projects are against the idea of honoring CLASSPATH. It helps us 
> though as we can replace all of your jars with ours quite easily.
> 
> Currently, a joint ``Linux'' standard, such as one for both JPackage and 
> Debian does not exist. Hopefully, it is forthcoming.

Yes (http://java.debian.net/index.php/CommonJavaPackaging)
However it is forthcoming because debian, jpackage, gentoo, rhug... all
face the same problems and wish for more or less the same things :

- source-only packages (no magic jars with strange undocumented versions
bundled to make the build work). No magic auto-download at build time

- a clean doc listing the external deps (what jars to use, where to get
them, what version was tested, what they are used for - are they
optional, test jars ?)

- a way to specify the classpath at buildtime. This means that for each
identified external dep we must be able to specify a classpath bit, bet
it via CLI switches, property files, or some other way. And I write
*classpath* bits because sometimes a jar has been replaced by two jars
or more which will break single-jar assumptions

- a signed hash of the source archives so we can be sure we are building
from the original uncompromised files

- follow external deps evolution. There is nothing more challenging than
to have to maintain twenty versions of the same package because we have
twenty applications in the repository that each need a different version
of the same dep

We had a more complete list on-line we'll point you to as soon a our web
site is back up again.

Anyway, just follow these simple guidelines for the time being and every
single java linux packager will praise your name daily;)

Cheers,

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Reply to: