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 ;-)) projects. 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. -Max ----- Original Message ----- From: "David Graham" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
