struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Cooper" <>
Subject Re: Status check?
Date Sun, 08 Jun 2003 11:57:23 GMT
I've gotten some requests for a list of library file versions for my
SecurityFilter project, so I've been looking into automatically creating a
file that lists the library file versions as part of my build. The idea was
to use the version information from the manifest files from the jars.
However, many projects do not provide this information in their jars, or at
least not the correct info.

The commons projects are pretty good compared to the other dependencies I
have, but commons-beanutils reports 1.6 for the 1.6.1 release, and
commons-digester has "1.5" (with the quotes) for the 1.5 release. The quotes
aren't a big deal since anyone reading it would correctly recognize it as
the 1.5 release. But commons-beanutils would mislead you to think you had
1.6 when it was really 1.6.1.

commons-logging has good version info
commons-codec has a good Implementation-Version number (which is what I
would use anyway)
commons-collections has good version info
jakarta-oro is pretty good, but adds a date and time to the
Implementation-Version in additon to the correct version number, which might
be confusing
I'm not sure about other commons (oops, I mean jakarta-commons ;-))

I think it is ideal to set things up so you can just do a cvs checkout or
update with a tag to get all the files you need to build a particular
release. It seems weird to tag another project's tree with your release,
though, if the current setup would require tagging commons project trees
when there is a Struts release. This is perhaps a good reason to commit the
library jars in the struts CVS tree, or do something Maven-like where your
project specifies what versions of external dependencies you need and it
retrieves them into a shared local repository. I think there is an Ant
extension that will do retrieval like Maven.

I don't know if you guys ever do this, but I have in the past moved some
files CVS repositories by moving the repository file (ends in ,v) itself.
After doing that a few times, I have given up the practice since it screws
up the history -- the file will be in the wrong place if you do a checkout
based on a tag that existed before the move. It's better to just remove the
old file and add it in the new location with a CVS client rather than
mucking with the repository files, but you get a discontinuity in the
history that way. I am hopeful that Subversion will support real moves, and
will catch on enough to displace CVS some day.


----- Original Message ----- 
From: "David Graham" <>
To: <>
Sent: Friday, June 06, 2003 1:48 PM
Subject: Re: Status check?

> It makes more sense to me to *not* tag the commons files with Struts.  The
> commons doesn't need to be notified every time Struts cuts a release.  The
> commons jars contain version information in their manifests so it would be
> very easy to recreate an old Struts build by looking there.
> David

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message