Since we don't really need it? Should we yank it from dist? see http://blogs.msdn.com/dotnetinterop/archive/2005/03/31/404087.aspx
thanks, dims
He had the complete set of problems, with endorsed directories, etc, etc. At least happyaxis.jsp identified the existence of trouble. Maybe we should extend it with log4j enhancements.
I do agree there is a problem with JAR files and it is more fundamental than just what we include here. Expect lots of coverage of this in the second edition of Java Development with Ant :)
-Java1.4's endorsed directories was a mistake. Java1.5 rolls things back a bit, by renaming the apache packages.
-signing doesnt cut it. Once you sign jars the classloader starts to act different; you cant add new code into the same packages 'cept when they are signed too. Which is painful in OSS stuff.
-The maven repository stuff is more interesting. If you have a central cache of files stored as /project/artifact-version.jar, then you can declarative switch versions. This is essentially .NET's GAC, without the strong names. You could use it with maven, ant, or something a bit like ant that only launches programs; an XML app launcher (tomcat uses ant for this, but I am doing the repository stuff in smartfrog for a managed launcher)
I've argued a bit on the apache repository mail list (centre of discourse about repository stuff on apache) for using strong names in versions. So instead of log4j-1.2.jar, you'd also have, via the wonder of symlinks
log4j-4f32acb4def.jar
the advantage of this approach is (a) no confusion about versions, (b) explicit security in your downloads, when you go
<library project="log4j" version="4f32acb4def" /> then the downloader can verify the checksum after download, as it has the checksum already.
------
returning to log4j, its less essential in java1.5 as it used to be. and pulling it stops the ant tasks telling you off for not having a non-default log4j config (that message really irritates me, I dont see why I should be told off by log4j there). So pulling it would be tractable. This person's problems go much deeper than log4j; they go into WAR vs EAR vs JBoss classloader policies.
-steve
