RE: Request to drop version number from log4j jar file name

[Thomas Tuft Muller <tt...@online.no>]

-1 re versioned jars
+1 re building CM systems that handles non-versioned jars consistently and
accurately

E.g. if you compile Log4j with a couple of extentions/changes you've done,
what do you call the jar?

log4j-1.2.4.my.little.patch.jar and log4j-1.2.4.my.little.pathced.patch.jar?
To call it log4j-1.2.4.jar is obviously wrong since it's not version 1.2.4
anymore. In my view it's much better to use a generic and consistent name,
and have other means of extracting the version.

--

Thomas



| -----Original Message-----
| From: Steve Cohen [mailto:SteveC@ignitesports.com]
| Sent: 20 June 2002 00:14
| To: Log4J Users List
| Subject: RE: Request to drop version number from log4j jar file name (
| WAS: Strange weblogic problem with new jarfile name )
|
|
| I don't know if I HAVE a vote, but from my earlier comments, it
| is not hard to guess that I too am
| +1 re: versioned jars
|
| -----------------------------------------------------------------
| Steve Cohen
| Sr. Software Engineer
| Ignite Sports, Inc.
| stevec@ignitesports.com
|
|
| -----Original Message-----
| From: Tumpach, Andrew J [mailto:ATUMPACH@amfam.com]
| Sent: Wednesday, June 19, 2002 3:11 PM
| To: Log4J Users List
| Subject: RE: Request to drop version number from log4j jar file name (
| WAS: Strange weblogic problem with new jarfile name )
|
|
| All my downloads seem to have versions in the zip file, e.g.:
|
| From Sun:
| jwsdp-1_0-windows-i586.exe, jsse-1_0_2-do.zip,
| java_xml_pack-summer02.zip, j2sdk-1_4_0-win.exe
|
| Apache:
| jakarta-tomcat-4.0.2.zip, jakarta-ant-1.3-bin.zip,
| Xerces-J-bin.1.4.3.zip, xalan-j_2_2_D11.zip
|
| JBoss:
| JBoss-2.4.4.zip
|
| They do have non-versioned jar names within the zips, but extract
| to paths containing version-named directories.  That said, I
| would prefer version numbers in jars to make it obvious at a
| glance what version it is.
|
| +1 versioned jars (assuming it's a democracy - <g>)
|
| Andrew
|
| -----Original Message-----
| From: Tom Caulkins [mailto:Tom.Caulkins@sas.com]
| Sent: Wednesday, June 19, 2002 2:45 PM
| To: 'Log4J Users List'
| Subject: Request to drop version number from log4j jar file name ( WAS:
| Strange weblogic problem with new jarfile name )
|
|
| To bring the discussion back to my original request... ;->
|
| This thread has brought to our attention an unexpected problem
| related to the log4j-1.2.x.jar file name.  Like Mr. Bridges, I
| would not claim that this is a log4j problem - it's quite clear
| it's a deficiency in the BEA code.
|
| Ceki replied to my original post, saying that this was the
| correct forum to make such a request, but I was not really
| informed as to the status of that request, and it's not clear to
| me what is involved in the decision process.  Is this just a
| unilateral decision to be made by Ceki, or is there some formal
| or informal decision making process among a core set of log4j
| developers?  If the version number was added because a user
| requested it, can it be dropped because another user or group of
| users requests that it be dropped?
|
| In any case, I would like to re-submit my request to drop the
| version number from the log4j jar file name.  Here are the
| reasons I included in my original post:
|
| * 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.
|
| * 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 would also like to point out that as far as I know, the other
| major players in the Java arena ( Sun, IBM,...BEA - ha, ha!, etc.
| ) are not adding version numbers to their jar file names.  While
| this certainly doesn't mean that log4j has to follow this
| convention, it does mean that log4j will be the exception to the
| rule ( which, by the way, makes it susceptible to coding errors
| such as we've seen here ;-> ).
|
| So please post a decision to this request.
|
| Thanks,
| Tom
|
| --
| To unsubscribe, e-mail:
| <ma...@jakarta.apache.org>
| For additional commands, e-mail:
| <ma...@jakarta.apache.org>
|
|
| --
| To unsubscribe, e-mail:
| <ma...@jakarta.apache.org>
| For additional commands, e-mail:
| <ma...@jakarta.apache.org>
|
|



*************************************************************************
Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights reserved. 
The information supplied in this email should be treated in confidence.
No liability whatsoever is accepted for any loss or damage 
suffered as a result of accessing this message or any attachments.

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

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