Managing versions of Apache Jakarta software
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]
RE: Managing versions of Apache Jakarta software
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/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
RE: Managing versions of Apache Jakarta software
Sam Ruby [mailto:[EMAIL PROTECTED]] wrote:
I very much like xml-commons-which.
http://cvs.apache.org/viewcvs.cgi/xml-commons/java/src/org/apache/env/
It seems very useful, and I've only view it briefly [so I am no expert] but
wouldn't it be better if classes/packages known or unknown to this tool
would just return some standard Version object? This tool seems to use
adhoc per component version mechanisms, or infers version information based
upon subtleties known of the per component implementation/interface. It
doesn't seem like this would scale well.
For example, if a convention could be created [like XXXBeanInfo, I guess]
where a class {package}Version.class [e.g. org.apache.axis.Version] were
expected to exist for each Package, and this were a bean that returned
name/major/minor/dependencies [and/or the Java Package attributes], could
not an amazing Which tool be written?
regards,
Adam
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Managing versions of Apache Jakarta software
There was a discussion about an enterprise distribution of jakarta and other open-source java technologies some time back on this list that resulted in starting oed project on SourceForge [which is pretty much dead at the moment :-( ]. Which may suggest that there's more to solving this problem than meets the eye.. I'm nervous about tackling it because I think that it would take a massive effort to gain the kind of acceptance it would need to be worthwhile.. It would be a real shame for the lack of an total automated solution to lead to the lack of a simple manual solution. If administrators can manually check the explicit version of a JAR, rather than comparing sizes/datestamps, that would be a major improvement over today. Correctly version stamping JARs (using ANT today, or ANT future) would make operational configuration a lot less throw a pile of JARs together and pray... I still believe a simple Version bean would be very powerful, and easy to adopt, but since nobody's taken up what I've written then I guess I'm not proposing anything original/compelling, and that perhaps this is a road already travelled w/o end success. If there is a forum where folk feel a complete proposal [for just a version/version dependency class, nothing more] might be worthwhile please let me know, otherwise I'll go back to lurking. Thanks in advance. regards, Adam -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
