commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [VFS] WIP specific release instructions
Date Thu, 05 May 2016 12:29:21 GMT
sebb <sebbaz@gmail.com> schrieb am Do., 5. Mai 2016 um 13:55 Uhr:

> On 5 May 2016 at 12:22,  <ecki@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 <elserj@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<elserj@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message