You might be right about he "safety" issue but trying to enforce this all the time across all projects is not real feasible. I don't think the plugin would hurt in either case and it prevents releases from getting accidentally uploaded to the snapshot repository.
Scott On Mar 2, 2011, at 6:26 AM, sebb <seb...@gmail.com> wrote: > On 2 March 2011 10:27, Marshall Schor <m...@schor.com> wrote: >> If we check the box in a Job configuration that says "Deploy artifacts to the >> Maven Repository" and specify the Apache Nexus Snapshot repo, what happens >> if a >> build starts right at the moment when the Apache Release plugin has renamed >> the >> POMs to a non-Snapshot release version and checked those into trunk, so it >> can >> tag a release candidate? >> >> I presume the build might check-out from trunk a release version and build >> it. >> Assuming the build completes without error, the post-processing would >> attempt to >> upload this non-Snapshot to the Apache Nexus snapshot repo (the URL in the >> job >> configuration says: >> >> https://repository.apache.org/content/repositories/snapshots ) >> >> Would our Nexus configuration or the Hudson Maven plugin realize that >> something >> was amiss, in this case, and block the deploy to the repo? >> >> If not, is the right "best practice" to disable deployment in the job build >> settings while doing release work, and re-enable it afterwards? > > Another approach is to never release directly from trunk. > > Checkout trunk into a clean workspace > Edit the POM etc to change the version and scm fields as necessary > > Do "svn diff" and "svn st" to check that the changes are OK. These > should only show changes to the POMs > > Create the RC tag, by copying the tag workspace to SVN: > > svn copy <workspace> https://svn.apache.org/.../tags/cmis-1.2-RC1 > > You can then release from that workspace directly (but remember it's > linked to trunk). > Or for safety, checkout a read-only copy of the tag. > > If the release vote fails, update trunk, and create RC2 etc. > If the release vote succeeds, rename RCn as the release version, e.g. > cmis-1.2-RC3 => cmis-1.2. > Any failed RCn tags can then be deleted. > > This approach precludes using the maven release plugin, but IMO is a > lot safer and easier to recover. > >> I found by googling this plugin for hudson: >> http://code.google.com/p/maven-hudson-ext-plugin/ which explicitly says it >> recognizes this situation and doesn't upload. But I don't think this is the >> plugin we have installed, because the label on the "Build Settings" is >> different. >> >> -Marshall Schor >>
