The following is from http://www.ibiblio.org/java/#recent
I have a request to make of the log4j team, as well as all the other Java programmers at the Apache Project, IBM alphaWorks, Sun, and everyone else who distributes JAR archives. Could you please attach a version number to all your JARs? I maintain several systems whose ext directories I try to keep in sync. However, it's extremely difficult to do this when there's no straight-forward way to look at log4j.jar (or xercesImpl.jar, servlet.jar, jedit.jar, saxon.jar, or any of the several dozen other jar archives I work with on a daily basis) and quickly tell which version it holds. I personally experience this problem mostly with XML related jars, but the problem is hardly unique to XML. It's especially problematic when some other software requires a particular version of a third-party jar. For instance, IBM alphaWorks' XML Security Suite works with Xerces 2.0 beta 2 but not earlier or later versions. The Apache XML Security project works with the release version of Xalan 2.2 or later. My own XInclude software works with Xerces 1.4.0 through 1.4.3 but not earlier or later versions. Mostly I just add numbers to the jar archives when I copy them into my ext directory. However, that step is often forgotten, and it's almost never been done when I'm working with somebody else's system (e.g. trying to debug some student's homework for him or her). And when a distribution like FOP bundles several third party jars like Batik and the Bean Scripting Framework, they often don't bother to tell you which version they've bundled. It would be much easier if all JARs included appropriate version numbers in their names. It's also important that JARs name themselves with their sources for JARs that may come from multiple places. A good example of what to do is the Bouncy Castle JCE implementation. It's called "bc-jce-jdk13-112.jar". You can tell at a glance that it's version 1.1.2 of the Bouncy Castle implementation of the Java Cryptography Extension for Java 1.3. Even if that isn't obvious, you most certainly won't confuse this with any other implementation of the JCE (of which there are several). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
