On Monday 09 April 2007 08:12, Marc Prud'hommeaux wrote: > I think that will generally work, but there is the issue of the > "maven-metadata.xml" file in the parent directory (e.g., http:// > people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/ > openjpa-project/maven-metadata.xml) that lists all of the releases. > If you release to a different location and then manually move over > the release subdirectories, the parent maven-metadata.xml won't > automatically be updated. You could manually add the line to those > files, but them the md5 and sha1 checksums would be wrong.
That is a correct observation. ASF releases are all about source code, the binary artifacts are not really part of the problem domain. I have never managed to figure out how people expect the workflow to be, but in my mind it is a matter of "Release Candidate" production prior to a "Release". In practical terms; the release candidate sources are "tagged" with the "rc" marker in the versions, and copied into a subversion directory for the purpose. The release candidate is cut and uploaded for review. And if not pass, then fix in trunk and repeat with a new "rc". Once the "rc" is approved for release, redo the tagging of the "rc" sources into a "released" directory and without the "rc" marker. And cut the release from there. Now, this assumes that for a given source repository, there is an automated process to cut the release, including checksumming, signing, uploading. It also requires that no changes are made in the "rc" and "released" directories, which I guess SVN ACL can take care of. Maven doesn't support this workflow, but if the "rc" and "released" are tagged into the same SVN directory, then it is close. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
