Re: Logging packaging questions

[Richard Sitze <rs...@us.ibm.com>]

1.  Log4j was eliminated from classpath (4/17).  Last release (1.0.3) is 
dated 4/7.  You need to push for a new release.

2/3.  We do have a 'core' package:  commons-logging-api.jar.

+1 to individual sub-jars for each logger implementation.

I believe the fundamental idea has been suggested before, we simply need 
someone with time on their hands.  Any of your users is welcome to submit 
a new build.xml.  We will want to maintain the existing 
commons-logging.jar (everything) for those who have become addicted to 
code they don't need in their runtime :-)

Separating the API's from the implemenations begs for separate versioning 
(API's ought to stay relatively stable, implementations should be 
versioned independently).  Without proper separation, this could get 
uglier than it needs to be.

<b>Is there a jakarta/apache process for versioning subcomponents 
independently?</b>

<ras>

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development



[ This message is crossposted between commons-dev and jpackage-discuss.
Please keep the crosspost while replying - most interested parties won't
be subscribed to more than one of the lists ]

Hi,

                 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