Hello, BTW: I would use "mvn verify" instead of "mvn package" (I am not sure what has changed for CP40)
(And yes the release plugin and the commons procedure for releases is a match in hell ,) Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Josh Elser <els...@apache.org> To: Commons Developers List <dev@commons.apache.org> Sent: Do., 05 Mai 2016 6:49 Subject: Re: [VFS] WIP specific release instructions sebb wrote: > Have a look at the scripts in > > http://svn.apache.org/viewvc/commons/scripts/ > > I used those for VALIDATOR and NET. Cool. Thanks for sharing. It would be good if the generic commons release documents referenced these if they are expected to be re-used by other commons projects' RMs. > On 4 May 2016 at 04:43, Josh Elser<els...@apache.org> wrote: >> Here's what I've been doing. The generic instructions are woefully >> incomplete (before someone chimes in again - no, not just because "VFS is a >> multi-module project"). I think I have this on point for rc1, so I'm writing >> it down here before I forget (we can figure out where it *should* go later). >> >> rc0 only: >> # Make the branch >> $ svn cp trunk branches/VFS-XXX >> $ cd branches/VFS-XXX >> # Set the proper versions >> $ mvn release:prepare > > We use a tag not a branch, but perhaps that is what the release plugin does. > In which case I assume the branch is taken to avoid mangling trunk? release:prepare doesn't do the tagging (this is what release:perform does). All it's really doing are some pre-condition checks and version updates. TBQH, I don't have any idea how the maven-release-plugin and SVN are remotely useful for the ASF's vote-then-promote process. That said, it's ok if I don't get it. This is what worked for me and I'm happy with it. If there's something obvious I could have done differently, great. >> --- >> >> # Or just set it to your JDK6 installation -- this works on OSX >> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.6) >> >> # Where ${asf.username} for me is "elserj" >> $ mvn clean package -Duser.name=${asf.username} > > No need to use package if using CP40 What are you using instead of `package` to build the code... > >> # Set back to 1.7 because my 1.6 installation has trouble deploying to nexus >> $ export JAVA_HOME=$(/usr/libexec/java_home -v1.7) > > So does mine; in which case use -Pjava-1.6 below. > >> $ mvn deploy -Prelease -Duser.name=${asf.username} >> >> # This is what could be consolidated via one invocation of `mvn site` >> $ mvn site:site site:stage >> >> # Move back to the root SVN repo >> $ cd ../.. >> $ svn cp branches/VFS-XXX tags/commons-vfs-project-XXX-rcN > > Isn't that what the release plugin does? > > You might find > > http://svn.apache.org/viewvc/commons/scripts/create_RC_tag.sh > > easier to use - it does it all for you without needing to create a > temporary branch. Cool. I didn't find these from the generic commons release document. >> -- >> >> Things not covered above: >> >> * Copying artifacts (tarballs/zips, xsums, and sigs) into >> dist.a.o/dev/commons/... (building md5/sha1 files) >> * Closing staging repo in Nexus > > That can be done using Nexus2DistDev.sh Again, great. It would have been good to know about these beforehand. > >> -- >> >> Some things that could still be improved that I didn't fix: >> >> * Artifacts in dist/target are renamed when they're installed/deployed, but >> not in the local directory. Should do a rename of the file on disk so that >> what is on the RM's computer matches what is in their m2 repo and ASF nexus. > > Or ignore the local copies and use Nexus2DistDev.sh which copies the > bin/src artifacts from Nexus and deploys to dist/dev and can remove > them from Nexus before closing the staging repo. > > AFAIK only the deploy directory (i.e. Nexus) has the hashes. > >> * `mvn site` which invokes site:site and site:stage automatically (which >> would make for a more natural build process -- `mvn deploy` would build the >> site automatically) > > I don't follow that. `mvn site` is invoking the "site" maven lifecycle phase. "mvn site:site` and `mvn site:stage` are invoking executions on the maven-site-plugin. These are two distinct kinds of actions. We can configure the maven-site-plugin (and/or other necessary tasks) to run at the 'site' lifecycle phase for a more 'natural' process. > >> Again, for now, this is just for my benefit. When this is all over, I'll try >> to add this all to the website. Please point out anything wrong/missing. >> Thanks. >> >> - Josh >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
