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="${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]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to