Well, at this point Adam, we don't so much has have a written guideline for creating a Jakarta release, so adding versioning to a non-existent guidelines poses something of a challenge :O)
I have started some notes for a Release Manager's guide at http://jakarta.apache.org/site/guides.html What would be most helpful is that if you rolled your notes and experiences into a HOW-TO that the Release Managers might easily follow. As a deployment manager using several Jakarta products, you sound like just the person to write it. It is really not possible for use to create a standard release mechanism by fiat. So the next best thing is to make the "right" way the easy way, but giving people some simple instructions to follow. We're all interested in versioning, and run into the same problems you have; it's really a matter of documenting a procedure people can follow, and that we can point to if missed. -Ted. ajack wrote: > > All, > > I've been lucky enough to have benefited from a lot of the excellent > packages put out be this community, e.g. ANT/XERCES/LOG4J/XALAN/SOAP2.2/AXIS > etc etc, and I thank you all for that. Recently however my utilization of a > lot of Apache software has bitten me (commons-logging in AXIS in this case), > and it all comes down to "JAR version hell" & conflicts between various > versions delivered with various components. > > Upon investigation I see that some Jakarta projects distribute JARs with > version information inside (notably log4j, XALAN) and some do not (notable > AXIS and commons-logging, which is sad since they are newer and changing, so > need it badly.) > > Please please please make it a standard that all Jakarta JARs are > distributed with correct version information in them. This will not resolve > the JAR hell of conflicts, but it will allow folk to be able to document > what exact versions they use of libraries & track down environmental issues. > > Just to attempt to help, here are some things I have found: > > Javasoft did provide a JAR versioning, albeit [unfortunately] in a manifest > file, not in the code [so not great for keeping in synch, IMHO]. > > http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecificat > ion.html > http://java.sun.com/products/jdk/1.2/docs/guide/versioning/ > http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html > > Here is a sample manifest from LOG4J: > > Manifest-version: 1.0 > > Name: org/apache/log4j/ > Implementation-Title: log4j > Implementation-Version: 1.1.3 > Implementation-Vendor: "Apache Software Foundation" > > Now, it occurred to me that ANT would be the best tool to use for keeping > manifest files in synchronization with code/releases, but I found [not that > there may not exist] no easy way to do this with built in commands. > > That said I saw a couple of ways of managing the manifest within apache ant > scripts, the simplest in log4j that does a search and replace in a template > jar to set the version string: > > <target name="prejar" depends="build"> > <mkdir dir="${jar.dest}"/> > <filter token="version" value="${version}" /> > <copy file="${manifest.src}" tofile="${jar.dest}/manifest.mf" > filtering="true"/> > </target> > > and then later used the manifest attribute on the jar task: > > <jar jarfile="${jar.dest}/log4j-core.jar" basedir="${javac.dest}" > ... > manifest="${jar.dest}/manifest.mf" > /> > > Please look at Jakarta projects to see if versioning is missing, and please > look at adding it. As I manage a deployment of a number of machines/domains > of jakarta software the easier I can determine versions the better for > resolving issues. I would believe this would help other users also. > > Thanks in advance of any consideration. > > regards, > > Adam > -- > Open Business Interchange: <http://www.openbiz.biz> > The Revolutionary B2Bi Web Service ... > > ---------------------------------------------------------------------------- > ---------------------------- > Here is the XALAN manifest: > > Manifest-Version: 1.0 > Main-Class: org.apache.xalan.xslt.Process > Created-By: 1.2.2 (Sun Microsystems Inc.) > Class-Path: jaxp.jar xerces.jar crimson.jar xml-apis.jar > > Name: org/apache/xml > Implementation-Vendor: Apache Software Foundation > Implementation-URL: http://xml.apache.org/xalan-j/dist/ > Implementation-Version: 2.2.D14 > Implementation-Title: org.apache.xml > Comment: DTM implementation and utilities > > Name: org/apache/xpath > Implementation-Vendor: Apache Software Foundation > Implementation-URL: http://xml.apache.org/xalan-j/dist/ > Implementation-Version: 2.2.D14 > Implementation-Title: org.apache.xpath > Comment: XPath engine > > Name: org/apache/xalan > Specification-Title: Java API for XML Processing > Specification-Vendor: Sun Microsystems Inc. > Implementation-Vendor: Apache Software Foundation > Implementation-URL: http://xml.apache.org/xalan-j/dist/ > Specification-Version: 1.1 > Implementation-Version: 2.2.D14 > Implementation-Title: org.apache.xalan > Comment: Main Xalan engine implementing TrAX/JAXP > > -- > 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]>
