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: neutral (athena.apache.org: local policy)
Message-ID: <475BE372.6010003@apache.org>
Date: Sun, 09 Dec 2007 13:45:38 +0100
From: Dennis Lundberg <dennisl@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: [all] m2 release process
References: <55afdc850712071058pef7e8d7tec6f5f4a7467b37@mail.gmail.com>
	 <4759B4AD.2020701@apache.org>
	 <55afdc850712071315h7ca3a1f0kccf0ecf1cdb67448@mail.gmail.com>
	 <4759D815.3020100@apache.org>
	 <55afdc850712071551n1b4b8fb3u74504a7dec71d964@mail.gmail.com>
 <55afdc850712071555x5a880abam6cc76b1c4904f2fc@mail.gmail.com>
In-Reply-To: <55afdc850712071555x5a880abam6cc76b1c4904f2fc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niall Pemberton wrote:
> On Dec 7, 2007 11:51 PM, Niall Pemberton <niall.pemberton@gmail.com> 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?
> 
> OK how about I just upload the artifacts manually - that seems the
> simpest solution. Then we can do a commons-parent release removing the
> dummy repository and upgrading to commons-skin 2.

I think that's a bad thing (tm) to do. The release plugin, deploy plugin 
et al takes care of all the heavy lifting when doing a release. Not 
using it for a release might cause unwanted effects, like bad meta data.

> Niall
> 
>> 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
>>>>
>>>>
>>>
>>> --
>>> 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
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org