sebb <seb...@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr: > On 5 May 2016 at 12:22, <e...@zusammenkunft.net> wrote: > > Hello, > > > > BTW: I would use "mvn verify" instead of "mvn package" (I am not sure > what has changed for CP40) > > CP40 changed the assembly plugin to run in the verify phase so it can > pick up any additional jars added to the package phase by component > poms. > [It's not possible to ensure the assembly plugin runs at the very end > of the assembly phase - see COMMONSSITE-87] > > Releases should be generated using > > mvn deploy -Prelease > > 'mvn package' should still work for generating jars. > > > (And yes the release plugin and the commons procedure for releases is a > match in hell ,) > > Not just Commons. > Any project which allows multiple RCs for the same release is affected. > The plugin works best where failed releases are abandoned and the > version bumped for the next RC. > It does not play well with retries. >
I wonder how the maven-release-plugin team does this. Don't they run into the same problems? > > [1] https://issues.apache.org/jira/browse/COMMONSSITE-87 > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
