Just as a heads up. There will be something that helps you manage version information in jars in the next release (1.5). It semi-automates declaration of library name and version and it also allows the jar to declare dependencies on other libraries. It does this according the following spec.
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. This is used because it is the spec the EJB/Servlet/Service containers all seem to be adopting for library management. For a simplified explanation you may want to look at the section titled "dependencies" in http://jakarta.apache.org/ant/myrmidon/librarys.html Anyways if there is a demand for this I can get it into the ant1.5 codebase earlier. On Fri, 29 Mar 2002 07:58, ajack wrote: > I guess you folk have seen so many adhoc suggestions that you tend to > attempt to form a consistent guideline out of them. I'm not convinced this > particular approach has sufficient merit, or that there aren't better ones, > it was just an idea I threw out based on initial findings. I am game to > contribute what I can, but is this the forum? Do I become some owner of > this, or what? I guess I need Jakarta contributions 101 before I go much > further... > > That said, I am not sure a guideline is the place to go, and if I am asked > to contributed, I guess I'd have to do it based upon my own beliefs. I feel > that document (or manifest) based version management is too passive. When I > found Javasoft's versioning mechanism was in JAR files it seemed clear why > it has so little adoption [hell, I thought nothing exists, and I'm sure > most folk think that.] Personally I feel investment would be better served > in a "commons-versioning" [just made that up, hope I didn't upset some > "version4j folk"] with some "active" classes (including dependency > checking, start-up logging of version numbers, etc). > > I wish Java had a java.lang.Version class, 'cos their java.lang.Package > class [from a few hours of poking at it & class loader] doesn't seem to cut > it. That said, if it doesn't, perhaps a commons-logging type package could > be formed, that filled the gap (and perhaps eventually showed Javasoft the > need for one.) > > regards, > > Adam > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 28, 2002 1:33 PM > To: Jakarta General List > Subject: Re: Managing versions of Apache Jakarta software > > > 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/VersioningSpecifica >t > > > 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 ... > > > > ------------------------------------------------------------------------- > >- -- Cheers, Pete --------------------------------------------------- For every complex problem there is a solution that is simple, neat and wrong --------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
