Re: Why is the version number included in the log4j jar file name?

[Ceki Gülcü <ce...@qos.ch>]

At 16:29 17.06.2002 -0400, Tom Caulkins wrote:
>Hello,
>
>I've looked through the archives of both the log4j-user and log4j-dev 
>newsgroups, and I've not found the answer to my question.  If the answer 
>is there, and I missed it, my apologies.

This was discussed a few months back although I can't find the reference.

>In previous versions of log4j, the jar file name was simply 
>log4j.jar.  Now it is log4j-1.2.4.jar.  Last month it was log4j-1.2.3.jar.

Indeed.

>Why is the version number now being included?

Because it makes it easy to identify the log4j version being used at a glance.

>Is this a decision that was made by the log4j development team, or is it a 
>mandate from Jakarta?

Jakarta usually does not intervene on such matters. (This is one of the 
major strengths of the Jakarta project and also one of its main weaknesses.)

>I think it's a bad idea to include a version number in a jar file name - 
>any jar file name, not just log4j.  I also think it's a bad idea for the 
>end-user to rename jar files that are provided by third parties, such as 
>Jakarta/log4j.  But without renaming, I see these problems:
>
>* All scripts that reference the jar file will need to be modified when 
>taking each minor release.  This would include scripts to build 
>applications, run programs, set classpaths, etc.

Indeed, this is an inconvenience.

>* Multiple versions of the jar file will end up in the system.  If it's in 
>the Java extensions directories, where class loading order cannot be 
>controlled, there will be cases where the wrong version of classes will be 
>found. ( I think I may have found some examples of this problem in 
>messages to this newsgroup when I searched the archive. )

Is this really really to version numbers in jars? I don't think so.

>Keep in mind that the jar file version is always available in the jar's 
>manifest.

True.

>For these reasons, I hope you will consider dropping the version number 
>from the log4j jar file name.  If this is a Jakarta decision, please let 
>me know where I should direct this request.

No, this is the right place.

The change followed a request by Elliotte Rusty Harold in February
2002 (See http://www.cafeaulait.org/2002february.html). Here is his
request:

    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).

We probably all agree version numbers in jars is a matter of personal
preference, not life and death.

>Thanks,
>Tom
>------------------------------------------
>
>Tom Caulkins
>Senior Systems Developer
>Platform Services - Business Intelligence Platform
>SAS Institute Inc.
>Tom.Caulkins@sas.com

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>