commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [all] m2 release process
Date Sun, 09 Dec 2007 14:27:34 GMT
Niall Pemberton wrote:
> 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?

The release plugin calls other plugins during its run, amongst them the 
deploy plugin. The "arguments" is to pass that to the deploy plugin as 
you suspected.

We might need to add a release-plugin configuration for this in a 
component or the parent. Need to play around with this a bit.

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

Fair enough. Do we agree that we should ditch the dummy repo from 
commons-parent?

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

This is configured in commons-parent-5 in the "rc" and "release" 
profiles, so you don't need to do *anything* in a component. The plugin 
is specifically for making sure that all artifacts include mandatory 
organization resources. The ASF has a special resourceBundle that 
includes the appropriate licensing files.

           <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-remote-resources-plugin</artifactId>
             <executions>
               <execution>
                 <goals>
                   <goal>process</goal>
                 </goals>
                 <configuration>
                   <resourceBundles>
 
<resourceBundle>org.apache:apache-jar-resource-bundle:1.3</resourceBundle>
                   </resourceBundles>
                 </configuration>
               </execution>
             </executions>
           </plugin>

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


-- 
Dennis Lundberg

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


Mime
View raw message