Axis contains an org.apache.axis.Version class, which has a getVersionString() method
and a main() which prints the version info to System.out. The version string comes
from a resource file, and is automatically updated by our ant build each time the jar
is put together. Being a SOAP engine, we also expose a SOAP service called Version
which allows remote querying of the Axis version.
I'm a definite +1 to version information in jars - please feel free to check out the
way we did it in Axis.
--Glen
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 4:12 AM
To: Jakarta General List
Cc: [EMAIL PROTECTED]
Subject: RE: 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.
A big +1, we asked this sometimes ago in jpackage projects since it's
really confortable to have jar name like log4j-1.1.3.jar, or
xerces-1.4.4.jar since it help you have ALL versions in the same place
and let you decide which you want to use. Also very usefull when you
want to go from a stable 1.x to a beta 2.x for example.
I forward the request to xml list since it really an important point,
may be not for the developpers but for users and packagers...
-
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
