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?
Edwin Goei wrote:
Thanks for the patch. Would you mind creating a bug report under
category crimson?
Done. #6607
--
Christophe
-
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:
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
At 8:27 AM -0500 2/21/02, Glen Daniels wrote:
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
Oh, I misunderstood what you were wanting.
A big -1 to naming all jars with version #s. I can't think of a bigger pain in the
keister than having to revamp my classpath settings every time a library revs.
I could see heading down a road where all the Apache jars do programatic(sp?) version
Alas, this doesn't work in Windows environments
Yes, that's sad, fortunatly you could still do a copy ;)
copy c:\java\log4j-1.1.3.jar c:\java\log4j.jar
log4j 1.2 is out :
del c:\java\log4j.jar
copy c:\java\log4j-1.2.jar c:\java\log4j.jar
dir c:\java\log4j*.jar let you determine
At 11:29 AM -0500 2/21/02, Glen Daniels wrote:
Oh, I misunderstood what you were wanting.
A big -1 to naming all jars with version #s. I can't think of a
bigger pain in the keister than having to revamp my classpath
settings every time a library revs.
You're still using the classpath for
[Elliotte Rusty Harold]
You're still using the classpath for jars? I only do that when I want
to change the classpath on a per-run basis, in which case I am
changing it and using the version number is not a problem. However,
for standard libraries like xerces.jar that are shared among
Thomas B. Passin wrote:
[Elliotte Rusty Harold]
You're still using the classpath for jars? I only do that when I want
to change the classpath on a per-run basis, in which case I am
changing it and using the version number is not a problem. However,
for standard libraries like xerces.jar that
[Berin Loritsch]
Thomas B. Passin wrote:
[Elliotte Rusty Harold]
You're still using the classpath for jars? I only do that when I want
to change the classpath on a per-run basis, in which case I am
changing it and using the version number is not a problem. However,
for standard
Thomas B. Passin wrote:
[Berin Loritsch]
Thomas B. Passin wrote:
any given app finds the right version?
For some jars like Xerces/Xalan, if you code to the plugable API (aka
JAXP), you only need to upgrade the jar--no recompilation or refactoring
needed.
For others, like the Commons
[Elliotte Rusty Harold]
If all those versions are in the ext directory, how do you make sure that
any given app finds the right version?
They aren't. I put in the one I need.
--
+---++---+
| Elliotte Rusty Harold | [EMAIL
A big +1 to adding version numbers to jar names
In Windows, I never preset my classpath: I have a simple batch file for each
project/codebase which uses the jars in the lib in my development tree to
set the correct and minimum classpath for my current work.
Otherwise, you'd have to update all
13 matches
Mail list logo
