commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: [all] m2 release process
Date Sun, 09 Dec 2007 13:40:17 GMT
Niall Pemberton wrote:
> On Dec 9, 2007 12:42 PM, Dennis Lundberg <> wrote:
>> Niall Pemberton wrote:
>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <> 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
>>>>>> Maven 1 specifics. But that's probably just me, because I'm used
>>>>>> doing releases with Maven 2 over in maven land. So this needs to
>>>>>> 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 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
>>>>> 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  is perhaps something to do
>>> with that? But for me that causes the NPE in the surefire plugin!!!!
>>> Which looks like these:
>>> 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

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.

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.

> 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
>>>>>> parts from Maven's own release processes, the old [2] and the new
>>>>>> 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]
>>>>>> [2]
>>>>>> [3]
>>>>>> 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
>>>>>>> options I need to use?
>>>>>>> tia
>>>>>>> Niall
>>>>>>> P.S. This is for commons-skin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Dennis Lundberg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message