commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <>
Subject Re: Logging packaging questions
Date Mon, 16 Jun 2003 19:35:19 GMT
Hey folks,

I would disagree if the jar sharing mechanism provided for versioning.  
There are several ways to accomplish this, but the maven repository does 
it in a very simple and practical way.  All that would be left to 
jpackage-type tools is the dynamic runtime classpaths.

Ryan Hoegg
ISIS Networks

David Graham wrote:

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message