commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: Logging packaging questions
Date Mon, 16 Jun 2003 19:18:29 GMT

Howdy,
I couldn't agree more, Senor Graham ;)

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: David Graham [mailto:dgraham1980@hotmail.com]
>Sent: Monday, June 16, 2003 3:17 PM
>To: jpackage-discuss@zarb.org; commons-dev@jakarta.apache.org
>Cc: hgomez@users.sourceforge.net
>Subject: Re: Logging packaging questions
>
>I don't work on commons-logging so I won't speak to satisfying your
request
>but I am curious about why you need this behavior.  I would *never*
allow
>all of my apps to share jars between them and upgrade them all at the
same
>time.  The amount of testing that would require is simply unreasonable
not
>to mention the fact that all apps aren't on the same
development/deployment
>cycle.  IMO, sharing jars in this way is asking for trouble.
>
>David
>
>
>>
>>	The jpackage project (http://www.jpackage.org/) is a volunteer
>project
>>devoted to providing clean linux rpm packages of java stuff. Since
Linux
>>core processes permit very fine control of what's actually installed
on
>>the system, one of our main goals is to enable component sharing
instead
>>of the usual java practise of having a copy of every single needed jar
>>in every single app. Since every library is only installed once on the
>>system, it must be installed right to please every user app. (OTOH
this
>>allows ugrading a component in every app at once instead of having to
>>rebuild all the users). Applications use a common script framework to
>>build classpathes out of available jars and/or create symlinks when
they
>>need directories of jars to run.
>>
>>	This is a rather unusual setup (even if our users love it) and
as a
>>result we tend to find problems other people miss. The most recent one
>>involves tomcat4,commons-logging and log4j. I won't bore you with
>>technicalities (the whole discussion is available at the
>>http://lists.zarb.org/pipermail/jpackage-discuss/2003-June/002084.html
>>url, and I think it even overflows in a few other threads) but we
found
>>we needed some changes in commons-logging jar structure and we'd
rather
>>have them into jakarta proper instead of branching stuff (we've been
>>providing official linux rpms of jakarta stuff and we'd rather keep it
>>that way).
>>
>>	Anyway :
>>
>>1. we absolutely need removal of the log4j classpath entries in the
>>generated jar manifests (as a rule we consider classpathes in
manifests
>>evil since they result in subtle behaviours no human can really
handle.
>>They won't work most of the time and when they do it's not like the
user
>>intended). We do not want log4j stealth-drawn into the classpath if
>>present like it is now and users want control of the actual logging
>>backend used.
>>
>>2. we'd like the build-in backends split from the main jar so we can
>>made them optional and allow people not to install them if they
already
>>have log4j or a 1.4 jvm.
>>
>>3. people have asked for further splittage of the backend glue so they
>>can only install the parts relevant to the backend they'll actually
use
>>(ie separate log4j, jdk 1.4, avalon... parts).
>>
>>	In linux speak that would get us :
>>
>>commons-logging frontend requires commons-logging-backend
>>commons-logging-log4 provides commons-logging-backend requires log4j
>>commons-logging-jdk provides commons-logging-backend requires java >=
>>1.4.0
>>commons-logging-simple provides commons-logging-backend
>>
>>and so on, each package consisting of a single jar with no classpath
in
>>its manifest.
>>
>>I realise I've not been as terse as I wanted to so I'll stop now. Just
>>ask if I wasn't clear enough.
>>
>>Regards,
>>
>>--
>>Nicolas Mailhot
>><< signature.asc >>
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message