On 17/12/2011 21:43, Konstantin Kolinko wrote: > 2011/12/17 Antonio Petrelli <antonio.petre...@gmail.com>: >> If you release to a staging directory, the Maven metadata (containg info >> about previous releases) are not there, so they are created from scratch. >> So, after releasing in the staging directory and voting, the copy method >> simply overwrite the old metadata with the new one (remember, *without the >> old versions*). >> So in the end, we needed to use the Maven stage plugin (deprecated), that: >> * downloads the staged artifacts; >> * reuploads them to the final destination. >> > > Mark, the above issue mentioned by Antonio is what I think we already > encountered with broken maven-metadata.xml. That is > > https://issues.apache.org/bugzilla/show_bug.cgi?id=52124 > > More detailed description is in > https://issues.sonatype.org/browse/MVNCENTRAL-139
That was a broken Tomcat 6 build process. Tomcat 7 doesn't have that problem (and now, neither does 6). Granted using Nexus would have avoided that issue but it has taken 5 years (since the 6.0.0 tag) for someone to complain. That suggests to me the issue is minor. > Mark, when you do 7.0 releases, do you scp the maven-metadata.xml file? I assume that the file gets correctly generated automatically. > Do you have all previous releases of 7.0 in your local repository (so > that the file is built correctly)? No. I have 7.0.11 - 7.0.23 (mainly because I haven't cleaned it out in a while). It looks like the build process grabs a copy of the metadata from the remote repo, updates it to add the new version and then uploads the updated file. > If Nexus allows to prepare new releases without the need to keep old > releases around, I am +1 for it. As far as I can tell, Nexus and the scp+rsync process are the same in this regard. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
