Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of niall.pemberton@gmail.com
 designates 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mSXbql+AWDXib2yd3gM9yZbjPgkpyW4GQtCryOHj5b5D1kslJGU4d8sAbtoLR2v5Rf57tNakxAwncu9j0BPWa4fUIiZgIyhnqk0NWYfTV6WqwyF8qj5gu9sbsYA7ZhL+In+wc1tQe9CFi1aJOARCwMx/2yq0l6qlgcspgNj0SxM=
Message-ID: <55afdc850712090611v21596bc6wdf9e817d00f524a0@mail.gmail.com>
Date: Sun, 9 Dec 2007 14:11:56 +0000
From: "Niall Pemberton" <niall.pemberton@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [all] m2 release process
In-Reply-To: <475BF041.9070804@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <55afdc850712071058pef7e8d7tec6f5f4a7467b37@mail.gmail.com>
	 <4759B4AD.2020701@apache.org>
	 <55afdc850712071315h7ca3a1f0kccf0ecf1cdb67448@mail.gmail.com>
	 <4759D815.3020100@apache.org>
	 <55afdc850712071551n1b4b8fb3u74504a7dec71d964@mail.gmail.com>
	 <475BE2B6.9020901@apache.org>
	 <55afdc850712090518h6f9d0bd8s2d5e7da167e03896@mail.gmail.com>
	 <475BF041.9070804@apache.org>

On Dec 9, 2007 1:40 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Dec 9, 2007 12:42 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> >> Niall Pemberton wrote:
> >>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> >>>> Niall Pemberton wrote:
> >>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> >>>>>> For logging I followed the current release procedure [1], which worked
> >>>>>> well. Sections 11 and 12 need to be merged somehow. As I'm not familiar
> >>>>>> with releases back in the Jakarta days, I'm not quite sure how to
> >>>>>> though. Other than that, it was obvious what to when the docs talk about
> >>>>>> Maven 1 specifics. But that's probably just me, because I'm used to
> >>>>>> doing releases with Maven 2 over in maven land. So this needs to be
> >>>>>> written down.
> >>>>>>
> >>>>>> For releases support artifacts that reside only in the Central repo
> >>>>>> (parent poms, skin) I have simply done:
> >>>>>> - vote based on svn revisions
> >>>>>> - mvn release:prepare
> >>>>>> - mvn -Prelease release:perform
> >>>>> OK I found this http://tinyurl.com/2h222s and was following that. "mvn
> >>>>> release:prepare -Prc" works fine but the first time i did "mvn
> >>>>> release:perform -Prc" (fogetting -Darguments="-Prc") and I couldn't
> >>>>> find where it went and from the logs it looked like it uploaded it to
> >>>>> "dummy" - so I undid the prepare and tried again with:
> >>>>>
> >>>>>    mvn release:perform -Prc -Darguments="-Prc"
> >>>>>
> >>>>> This time it threw a NullPointerException in the SurefirePlugin(line 594)
> >>>>>
> >>>>> So can I do "mvn -Prelease release:perform" without having to revert
> >>>>> the version 2 tag? If so how?
> >>>> We seriously need to remove the "dummy" repo setting from the parent
> >>>> pom. It does nothing but cause grief.
> >>>>
> >>>> If we remove it, calling 'mvn release:perform will copy the artifacts to
> >>>> the snapshot repo if the version is a SNAPSHOT, and to the
> >>>> central-sync-repo if it's a "real" version. We have to trust ourselves
> >>>> to call the right commands, not having to remember which non-standard
> >>>> command-line switch to add. Just use Maven the way it is.
> >>> OK but using -Prelease should override the deployment repository and
> >>> when you do mvn help:effective-pom -Prelease everything looks good.
> >>> Seems that something though is still picking up that dummy repository
> >>> though and I'm guessing the -Darguments="-Prelease" that Torsten
> >>> mentions here http://tinyurl.com/2h222s  is perhaps something to do
> >>> with that? But for me that causes the NPE in the surefire plugin!!!!
> >>> Which looks like these:
> >>>
> >>> http://jira.codehaus.org/browse/SUREFIRE-314
> >>> http://jira.codehaus.org/browse/SUREFIRE-300
> >>>
> >>> I even tried adding -Dmaven.test.skip=true but it still threw the NPE.
> >>>
> >>> So is there a way round to resolve this with the situation as it is or
> >>> does it need a commons-parent release first to remove the dummy repo?
> >> I think these problems start if you forget to use the proper profile in
> >> the first place, when doing 'mvn release:prepare'. After that you're
> >> toast no matter what options you throw at Maven on the command line.
> >
> > I don't really understand this - are not both the profiles ("rc" and
> > "release") we have "proper profiles" - just with a different
> > distribution destination? I tried with both.
>
> Yes they are. What I think is needed with our current setup is to do:
>
> mvn -Prelease release:prepare
> mvn -Prelease release:perform

That was what I tried to do first time - except using the "rc" profile
(and user and password options) and it appeared to try to deploy to
"dummy" - thats what seems like a bug in maven to me.

The second time I tried the above using the "release" profile, but
with Torsten's suggestion (http://tinyurl.com/2h222s) of adding
-Darguments="-Prelease" - that gave the NPE. I don't know what passing
value "-Prelease" for "arguments" does (btw I also see in the commons
logging pom the maven-release-plugin has a configuration valeu of
"-Prelease" for "arguments") but I'm guessing its so that the deploy
bit picks up the correct profile and doesn't use the "dummy"
reposotiry specified in the commons-parent distribution voodoo?

> When you do release:prepare maven prepares a pom that is used during the
> release process. A very neat way to see what is *going* to happen is to
> do a simulation, called a "dry run". This runs release:prepare locally
> without checking in anything in svn. It produces a couple of files
> locally that represents the different versions that would have been
> checked in, had it been a real (non-dry run) release. Here is the
> command, if you want to try it:
>
> mvn -Prelease release:prepare -DdryRun=true
>
> If you want to clean up the files that were created by the above
> command, you can run this one. Do NOT run this command on a real release
> in progress though.
>
> mvn release:clean
>
> > Clearly you know more about this than me - but from what I could see
> > my attempts to release were frustrated by two maven bugs 1)
> > incorrectly picking up the "dummy" repository and 2) a NPE when using
> > "-Darguments". If this is not the case and it was some screw up by me
> > then I'd really like to know which bit a did wrong.
>
> 1) is not a maven bug, but rather something we have invented here in
> commons. That's why I would like to remove it. Maven already handles
> deployment to the correct place, without the dummy repo config.

Well I'm still not convinced that maven picking up the "dummy"
repository when a profile has been specified that overrides it is not
a maven bug.

> 2) I managed to work around this, without a need to upgrade to
> commons-parent-6-SNAPSHOT. Unfortunately svn seems to be down currently :-(
>
> With the changes I have locally right now, I'm able to produce a jar
> file with automatic insertion of license and notice files. The manual
> files you added to src/main/resources/ are not needed for this to work.

Is not having the LICENSE and NOTICE files added simpler? I don't know
how the remote resources plugin works - and I couldn't see anything in
the logging pom where that was configured. But a couple of static
files rather than more maven configuration voodoo seems simpler to me.

Niall

> > Niall
> >
> >> I'll have a look at the skin to see if I can resolve this.
> >>
> >>
> >>> Niall
> >>>
> >>>>> Niall
> >>>>>
> >>>>>> I'd be happy to help write some more docs for this. We can borrow some
> >>>>>> parts from Maven's own release processes, the old [2] and the new [3].
> >>>>>> How do we want to structure the docs?
> >>>>>>
> >>>>>> 1. One document that includes all releases, whether it's Ant, Maven 1 or
> >>>>>> Maven 2
> >>>>>> 2. Separate documents depending on which tool is used to do the release
> >>>>>> 3. Something else...
> >>>>>>
> >>>>>>
> >>>>>> [1] http://commons.apache.org/releases/release.html
> >>>>>> [2] http://maven.apache.org/developers/release/pmc-release-process.html
> >>>>>> [3] http://maven.apache.org/developers/release/releasing.html
> >>>>>>
> >>>>>>
> >>>>>> Niall Pemberton wrote:
> >>>>>>> I haven't done an m2 release before - do we have it documented
> >>>>>>> anywhere or can someone give me some pointers on what commands and
> >>>>>>> options I need to use?
> >>>>>>>
> >>>>>>> tia
> >>>>>>>
> >>>>>>> Niall
> >>>>>>>
> >>>>>>> P.S. This is for commons-skin
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> 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