Good point they made there, but.... ;-) However, version information in the filename does not seem that comfortable. Replacing jar files will not be that easy, maintaining dependencies (and updating them when new versions are available) will be a hassle I think.
At my company, we're petting them in the manifest, according to the specification by Sun (http://java.sun.com/products/jdk/1.2/docs/guide/jar/manifest.html). Just integrate a timestamp like or version like thingy in your 'template' manifest and let Ant replace it by the actual version information and/or timestamp. This way, your manifest will look something like the example given below. Besides that, we have a very simple graphical tool in which you can select a directory and all the manifests of the jars in the dir are retrieved and version info is displayed... Manifest-Version: 1.0 Specification-Title: Classifier Logic Specification-Vendor: SmartHaven B.V. Created-By: Ant Automated Build - 6 February 2002 10:13 AM - build Implementation-Vendor: SmartHaven B.V. Specification-Version: 1.1 Implementation-Version: MAIN-b345 - 6 February 2002 10:13 AM Implementation-Title: Classifier Logic Alef Arendsen SmartHaven > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 21 February 2002 07:52 > To: [EMAIL PROTECTED] > Subject: version numbers in jars > > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
