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.
Saving disk space is the only reason I can think of for sharing a version of a jar and I highly doubt anyone needs to save 1MB of space in a server application. Amongst other things, sharing jars leads to classloader problems.
David
-- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
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 (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 >>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]