On Tue, Mar 29, 2011 at 10:08 AM, sebb <seb...@gmail.com> wrote: > On 29 March 2011 16:02, Niall Pemberton <niall.pember...@gmail.com> wrote: >> On Tue, Mar 29, 2011 at 3:50 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>> After another nightmare by an RM who has not cut a release in a >>> while, I think we need to do something. The documentation on the >>> Commons web pages describes a process that works. I suggest that we >>> standardize on that process, adding some simple automation scripts >>> that RMs can choose to use or not to use for the manual steps and >>> stop fussing with Nexus or the maven release plugin. I cut an RC > > We need to keep Nexus, but I agree about the release plugin - see below. > >>> last night in 25 minutes (about 15 of which were spent waiting for >>> the [pool] tests to complete) and will likely spend about that same >>> amount of time deploying the artifacts to dist/ and what remains of >>> our simple, file-and-directory-based replication infrastructure to >>> get maven artifacts pushed to the maven repos. I do use a simple >>> shell script to manage invoking the maven commands and copying files >>> around to reduce the required time from, say an hour, to 25 >>> minutes. The script is in svn. >>> >>> I prefer the "manual" approach for the following reasons: >>> >>> 1. I know what it does. Exactly, every time. I know that exactly >>> the binaries that we vote on get deployed to dist/ and exactly the >>> committed tag is used to build everything. The process includes >>> local generation of artifacts that I can inspect and test locally >>> and verify sigs. I know at each step exactly what is being pushed >>> where. >>> >>> 2. I know that it works. Every time. No pom-tweaking, >>> plugin-munging or other half-success management required. >>> >>> 3. It has no commercial / proprietary dependencies. The scripts >>> are optional and are in any case, ASF-licensed, committed to svn. >>> >>> I know others have different opinions on this. It could be we need >>> to support both ways of cutting releases. >> >> AIUI then the deployment to the maven repository is either by dropping >> the artifacts manually in >> http://people.apache.org/repo/m2-ibiblio-rsync-repository/ OR by using >> Nexus. I think once a component switches to Nexus, then the manual >> process doesn't work. > > Yes, that is true. > > Also, had the [net] release been using Nexus, it would have required 2 > additional manual stages to close and then release the Maven > artifacts. > It is impossible to accidentally release Maven artifacts using Maven > command-line when using a staging manager such as Nexus. > > But I agree that using manual processes up to that point is better > than trying to use the Maven release plugin.
My assumption is that the Nexus stuff is supposed to work and make life easier. If it doesn't, I suppose we shouldn't use it. Is it a training issue, such that none of us simply knows exactly what it is we ought to expect the process to do, and how it will do it? This type of thing is my chief complaint about Maven in general: it's hard to understand what's going on once you get a level or two of parent POMs in there. If it's just a matter of "we haven't discovered the precise incantations that make the release plugin + Nexus instance do what we mean with no fuss," perhaps we could cajole Brian Fox into walking one of us (who solemnly vows to document the entire experience in full detail) through the entire lifecycle. Matt > >> Niall >> >>> I would ask, however, >>> that those arguing for the "automagical" approach take a hard look >>> at how many volunteer hours are being spent trying to get >>> maven/nexus to be a release manager and how comparatively little >>> time those of us who take the "manual" approach spend getting our >>> releases built and deployed. While I certainly can't claim to >>> produce perfect artifacts (much less code :), I will also point out >>> that the only major release quality problem that we have had >>> recently was the inadvertent release of a [net] version while >>> fiddling with the release plugin. I don't at all buy the argument >>> that the manual approach is "error-prone" as it allows more and >>> better opportunities for inspection by the RM and community at each >>> stage. >> >> >> >> >>> Phil >> >> --------------------------------------------------------------------- >> 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
