On 29 March 2011 18:33, Niall Pemberton <niall.pember...@gmail.com> wrote: > On Tue, Mar 29, 2011 at 5:18 PM, sebb <seb...@gmail.com> wrote: >> On 29 March 2011 16:52, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 3/29/11 8:33 AM, sebb wrote: >>>> On 29 March 2011 16:20, Matt Benson <gudnabr...@gmail.com> wrote: >>>>> 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. >>>> Nexus is effectively a proxy, and has little bearing on how Maven >>>> deploy or release work. >>>> The artifacts end up in Nexus rather than in a directory that is >>>> auto-synched to Maven Central. >>>> >>>> This makes it easy to review the actual artifacts that will be >>>> deployed, as well as ensuring that artifacts cannot be accidentally >>>> deployed. >> >> Sorry, I was referring to the Maven artifacts, which is what went >> wrong with Net. >> >>> I disagree with this. The most important artifacts are the >>> zips/tars that go to dist/. These *are* the ASF release. Nexus >>> makes it *harder* IMO to maintain provenance of these artifacts. >> >> AIUI the ASF release is the *source*, which is normally also released to >> Maven. > > IMO I don't quite agree with what either you or Phil said. The release > is whatever artefacts that we put out there for users to download. ASF > requires that we do a source release and anything else is a > convenience - but those other things are part of the release.
Yes, I agree they are part of what we in Commons consider a release, but AIUI that is not the strict ASF position. My point was that it was not only the dist/ artifacts that matter. > >> We don't have to use Nexus for non-Maven artifacts. >> >> IIRC, previously there was little or no visibility of what Maven >> artifacts would be released, and they were not always voted on. > > Rubbish. You make it sound like we only started checking maven > artifacts since Nexus. That was not my intention. I thought I had seen several votes where the Maven artifacts that were eventually released were not the exact ones voted on, because the release process that was used forced the RM to rebuild the jars in order to deploy them. But maybe I'm thinking of a different project. == Nexus makes it easier to release Maven artifacts, as there is no need to mess with the maven-metadata.xml file [1] [1] http://commons.apache.org/releases/release.html#a3_Deploy_Maven_Artifacts --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
