You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2007/12/07 19:58:40 UTC
[all] m2 release process
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
Re: [all] m2 release process
Posted by Ben Speakmon <bs...@apache.org>.
I did email 1.1 with it; I updated the release docs in commons-build with
some of what I learned. The only part not documented is publishing m2
artifacts to maven.org, but I was able to figure it out without much
trouble.
On Dec 7, 2007 10:58 AM, Niall Pemberton <ni...@gmail.com> 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
>
>
Re: [all] m2 release process
Posted by Ben Speakmon <bs...@apache.org>.
Also, since we sign RCs instead of just the final approved build, that part
of the doc should move to preparation instead of release.
On Dec 7, 2007 1:01 PM, Dennis Lundberg <de...@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
>
> 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
>
>
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 8, 2007 4:06 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>> On 12/7/07, Dennis Lundberg <de...@apache.org> wrote:
>> <snip/>
>>> 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
>>>
>> <snap/>
>>
>> This makes sense. However, I think we're better off staging skin
>> (which, unlike poms, actually requires building jar files so there is
>> some processing of the artifacts in the svn rev / tag).
>
> Good point - that would have been a better way to do the release -
> esp. in light of the fact that currently it doesn't include the
> license and notice in the jars
Agreed.
>
> Niall
>
>> -Rahul
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 8, 2007 4:06 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> On 12/7/07, Dennis Lundberg <de...@apache.org> wrote:
> <snip/>
> >
> > 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
> >
> <snap/>
>
> This makes sense. However, I think we're better off staging skin
> (which, unlike poms, actually requires building jar files so there is
> some processing of the artifacts in the svn rev / tag).
Good point - that would have been a better way to do the release -
esp. in light of the fact that currently it doesn't include the
license and notice in the jars
Niall
> -Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/7/07, Dennis Lundberg <de...@apache.org> wrote:
<snip/>
>
> 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
>
<snap/>
This makes sense. However, I think we're better off staging skin
(which, unlike poms, actually requires building jar files so there is
some processing of the artifacts in the svn rev / tag).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 10, 2007 9:07 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Dec 9, 2007 11:02 PM, Niall Pemberton <ni...@gmail.com> wrote:
> >> On Dec 9, 2007 2:27 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>> Niall Pemberton wrote:
> >>>> On Dec 9, 2007 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>>> Niall Pemberton wrote:
> >>>>>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>>>>> Niall Pemberton wrote:
> >>>>>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>>>>>>> Niall Pemberton wrote:
> >>>>>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
> >> or the profiles?...see below
> >>
> >>
> >>>>> 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?
> >> As a change in isolation that would seem like a bad idea. From where I
> >> sit the dummy repo is sympton of the problem rather than cause - the
> >> real issue being why the deployment step doesn't pick up the correct
> >> repo from the profile being used.
> >>
> >> Wouldn't it be better to configure the maven-release-plugin in the
> >> "rc" profile with an "arguments" value of "-Prc" and in the "release"
> >> profile with an "arguments" value of "-Prelease"?
> >>
> >>>>> 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.
> >> OK that didn't happen either when I did the release (but it does if I
> >> do mvn -Prc package) - so perhaps this is the same kind of issue - you
> >> need to pass an "arguments" value specifying the profile - otherwise
> >> when the remote resources plugin gets called its also no operating on
> >> the correct profile?
> >>
> >> I'll remove the license and notice files I added and see if I can
> >> stage the commons-skin using the "rc" profile - it should now work
> >> with arguments="-Prc" now that you've added -Dmaven.test.skip=true to
> >> the commons-skin pom
> >
> > Another thought - since all of our components already have license and
> > notice files this will mean that we'll now have jars produced with
> > duplicate license/notice files. I just tried running "mvn -Prc
> > package" for Validator - the standard and sources jars produced both
> > had duplicate license/notice files (javadoc jar had none). Also the
> > generated notice file says it uses beanutils and oro "developed by an
> > unknown organization" which doesn't look too great.
>
> I believe that the notice content is picked up from the meta data in the
> repository, but I'm not sure. So this will get better as time passes and
> new releases with better meta data are available.
I've opened a Jira ticket to discuss pom changes here:
https://issues.apache.org/jira/browse/COMMONSSITE-21
Niall
> > Niall
> >
> >> Niall
> >>
> >>
> >>> <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
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 9, 2007 11:02 PM, Niall Pemberton <ni...@gmail.com> wrote:
>> On Dec 9, 2007 2:27 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> Niall Pemberton wrote:
>>>> On Dec 9, 2007 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>> Niall Pemberton wrote:
>>>>>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>> Niall Pemberton wrote:
>>>>>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>>>>> Niall Pemberton wrote:
>>>>>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
>> or the profiles?...see below
>>
>>
>>>>> 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?
>> As a change in isolation that would seem like a bad idea. From where I
>> sit the dummy repo is sympton of the problem rather than cause - the
>> real issue being why the deployment step doesn't pick up the correct
>> repo from the profile being used.
>>
>> Wouldn't it be better to configure the maven-release-plugin in the
>> "rc" profile with an "arguments" value of "-Prc" and in the "release"
>> profile with an "arguments" value of "-Prelease"?
>>
>>>>> 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.
>> OK that didn't happen either when I did the release (but it does if I
>> do mvn -Prc package) - so perhaps this is the same kind of issue - you
>> need to pass an "arguments" value specifying the profile - otherwise
>> when the remote resources plugin gets called its also no operating on
>> the correct profile?
>>
>> I'll remove the license and notice files I added and see if I can
>> stage the commons-skin using the "rc" profile - it should now work
>> with arguments="-Prc" now that you've added -Dmaven.test.skip=true to
>> the commons-skin pom
>
> Another thought - since all of our components already have license and
> notice files this will mean that we'll now have jars produced with
> duplicate license/notice files. I just tried running "mvn -Prc
> package" for Validator - the standard and sources jars produced both
> had duplicate license/notice files (javadoc jar had none). Also the
> generated notice file says it uses beanutils and oro "developed by an
> unknown organization" which doesn't look too great.
I believe that the notice content is picked up from the meta data in the
repository, but I'm not sure. So this will get better as time passes and
new releases with better meta data are available.
> Niall
>
>> Niall
>>
>>
>>> <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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 9, 2007 11:02 PM, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Dec 9, 2007 2:27 PM, Dennis Lundberg <de...@apache.org> wrote:
> >
> > Niall Pemberton wrote:
> > > On Dec 9, 2007 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >> Niall Pemberton wrote:
> > >>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >>>> Niall Pemberton wrote:
> > >>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >>>>>> Niall Pemberton wrote:
> > >>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
>
> or the profiles?...see below
>
>
> > >> 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?
>
> As a change in isolation that would seem like a bad idea. From where I
> sit the dummy repo is sympton of the problem rather than cause - the
> real issue being why the deployment step doesn't pick up the correct
> repo from the profile being used.
>
> Wouldn't it be better to configure the maven-release-plugin in the
> "rc" profile with an "arguments" value of "-Prc" and in the "release"
> profile with an "arguments" value of "-Prelease"?
>
> > >> 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.
>
> OK that didn't happen either when I did the release (but it does if I
> do mvn -Prc package) - so perhaps this is the same kind of issue - you
> need to pass an "arguments" value specifying the profile - otherwise
> when the remote resources plugin gets called its also no operating on
> the correct profile?
>
> I'll remove the license and notice files I added and see if I can
> stage the commons-skin using the "rc" profile - it should now work
> with arguments="-Prc" now that you've added -Dmaven.test.skip=true to
> the commons-skin pom
Another thought - since all of our components already have license and
notice files this will mean that we'll now have jars produced with
duplicate license/notice files. I just tried running "mvn -Prc
package" for Validator - the standard and sources jars produced both
had duplicate license/notice files (javadoc jar had none). Also the
generated notice file says it uses beanutils and oro "developed by an
unknown organization" which doesn't look too great.
Niall
> Niall
>
>
> > <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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 9, 2007 2:27 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Dec 9, 2007 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>> Niall Pemberton wrote:
> >>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>>>> Niall Pemberton wrote:
> >>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
or the profiles?...see below
> >> 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?
As a change in isolation that would seem like a bad idea. From where I
sit the dummy repo is sympton of the problem rather than cause - the
real issue being why the deployment step doesn't pick up the correct
repo from the profile being used.
Wouldn't it be better to configure the maven-release-plugin in the
"rc" profile with an "arguments" value of "-Prc" and in the "release"
profile with an "arguments" value of "-Prelease"?
> >> 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.
OK that didn't happen either when I did the release (but it does if I
do mvn -Prc package) - so perhaps this is the same kind of issue - you
need to pass an "arguments" value specifying the profile - otherwise
when the remote resources plugin gets called its also no operating on
the correct profile?
I'll remove the license and notice files I added and see if I can
stage the commons-skin using the "rc" profile - it should now work
with arguments="-Prc" now that you've added -Dmaven.test.skip=true to
the commons-skin pom
Niall
> <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 9, 2007 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>>>> Niall Pemberton wrote:
>>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 9, 2007 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> >>>> Niall Pemberton wrote:
> >>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>>>> Niall Pemberton wrote:
>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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
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 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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 9, 2007 12:42 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
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.
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
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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'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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 7, 2007 11:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>>> Niall Pemberton wrote:
>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 8, 2007 4:00 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> On 12/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> <snip/>
> >
> > OK how about I just upload the artifacts manually - that seems the
> > simpest solution.
> <snap/>
>
> Sounds good. Do the jars contain LICENSE / NOTICE files? Just saw that
> skin-1.0 jars do not!
Unfortunately not :(
> > Then we can do a commons-parent release removing the
> > dummy repository and upgrading to commons-skin 2.
> >
> <snip/>
>
> We need some discussion on that, since:
>
> * Haven't seen an answer as to why the dummy repo gets chosen i.e.
> given the current setup for commons-skin, whether m2 / deploy-plugin
> should (theoretically) choose it in the first place? It would seem
> that it wasn't chosen atleast once before (which would be how the 1.0
> release was cut), perhaps that is due to differences in plugin
> versions used -- which we can lock down, settings.xml minutiae etc.
>
> * As already pointed out, non-snap versions should never deploy to
> rsync repo directly (AIUI, purpose of dummy).
>
> -Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Rahul Akolkar wrote:
> On 12/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> <snip/>
>> OK how about I just upload the artifacts manually - that seems the
>> simpest solution.
> <snap/>
>
> Sounds good. Do the jars contain LICENSE / NOTICE files? Just saw that
> skin-1.0 jars do not!
I'll take a look at that.
>
>> Then we can do a commons-parent release removing the
>> dummy repository and upgrading to commons-skin 2.
>>
> <snip/>
>
> We need some discussion on that, since:
>
> * Haven't seen an answer as to why the dummy repo gets chosen i.e.
> given the current setup for commons-skin, whether m2 / deploy-plugin
> should (theoretically) choose it in the first place? It would seem
> that it wasn't chosen atleast once before (which would be how the 1.0
> release was cut), perhaps that is due to differences in plugin
> versions used -- which we can lock down, settings.xml minutiae etc.
I think that we have looked down the versions of all plugins by now. If
we haven't - let's do it.
> * As already pointed out, non-snap versions should never deploy to
> rsync repo directly (AIUI, purpose of dummy).
>
> -Rahul
>
> ---------------------------------------------------------------------
> 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
Re: [all] m2 release process
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/7/07, Niall Pemberton <ni...@gmail.com> wrote:
<snip/>
>
> OK how about I just upload the artifacts manually - that seems the
> simpest solution.
<snap/>
Sounds good. Do the jars contain LICENSE / NOTICE files? Just saw that
skin-1.0 jars do not!
> Then we can do a commons-parent release removing the
> dummy repository and upgrading to commons-skin 2.
>
<snip/>
We need some discussion on that, since:
* Haven't seen an answer as to why the dummy repo gets chosen i.e.
given the current setup for commons-skin, whether m2 / deploy-plugin
should (theoretically) choose it in the first place? It would seem
that it wasn't chosen atleast once before (which would be how the 1.0
release was cut), perhaps that is due to differences in plugin
versions used -- which we can lock down, settings.xml minutiae etc.
* As already pointed out, non-snap versions should never deploy to
rsync repo directly (AIUI, purpose of dummy).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 7, 2007 11:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
>
> On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> > Niall Pemberton wrote:
> > > On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
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
Re: [all] m2 release process
Posted by Torsten Curdt <tc...@apache.org>.
> 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:
I had to set the "arguments" because otherwise the maven multi
project release did not work. It looked as if otherwise the sub
projects where not using the release profile.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 7, 2007 11:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> Niall Pemberton wrote:
> > On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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?
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
Re: [all] m2 release process
Posted by Wendy Smoak <ws...@gmail.com>.
On Dec 7, 2007 4:32 PM, Dennis Lundberg <de...@apache.org> wrote:
> 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.
Releases need to be staged for the vote, so you can't let it deploy
directly to m2-ibiblio-rsync-repo where it would be synced
immediately.
I'd suggest overriding the distributionManagement url to something
like scp://people.apache.org/www/people.apache.org/builds/commons/m2-staging-repository
.
(Actually I prefer to stage each release separately, which can be done
by using properties such as ${version} in the url -- might be more
complicated for commons though.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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.
>
> 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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 7, 2007 9:31 PM, Ben Speakmon <bs...@apache.org> wrote:
> I remember when I did it that I had checked out the tag from SVN and done
> the release:perform voodoo from there. I didn't get anywhere fast with
> -DconnectionUrl, but I couldn't tell you why not.
The -DconnectionUrl voodoo seemed to work OK - it created a
"target/checkout" directory with the right pom and built a
commons-skin-2.jar that looks OK. The problem is where is it then
uploading to, the logs say the following..
<snip>
[INFO] [deploy:deploy]
altDeploymentRepository = null
Uploading: /org/apache/commons/commons-skin/2/commons-skin-2.jar
29K uploaded
[INFO] Retrieving previous metadata from dummy
[INFO] Uploading repository metadata for: 'artifact
org.apache.commons:commons-skin'
[INFO] Retrieving previous metadata from dummy
[INFO] Uploading project information for commons-skin 2
Uploading: /org/apache/commons/commons-skin/2/commons-skin-2-sources.jar
27K uploaded
</snip>
> *kicking self for not documenting that at time, KNEW it was gonna come back
> to haunt me*
>
>
> On Dec 7, 2007 1:27 PM, Niall Pemberton <ni...@gmail.com> wrote:
>
> > On Dec 7, 2007 9:15 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > > On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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?
> >
> > OK I tried the following:
> >
> > mvn -Prelease release:perform
> > -DconnectionUrl=scm:svn:
> > https://svn.apache.org/repos/asf/commons/proper/commons-skin/tags/commons-skin-2
> >
> > but I still can't see where its gone (doesn't seem to be in
> > m2-snapshot-repository or m2-ibiblio-rsync-repository) and logs seem
> > to indicate its being uploaded to "dummy" - any ideas?
> >
> > 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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] m2 release process
Posted by Ben Speakmon <bs...@apache.org>.
I remember when I did it that I had checked out the tag from SVN and done
the release:perform voodoo from there. I didn't get anywhere fast with
-DconnectionUrl, but I couldn't tell you why not.
*kicking self for not documenting that at time, KNEW it was gonna come back
to haunt me*
On Dec 7, 2007 1:27 PM, Niall Pemberton <ni...@gmail.com> wrote:
> On Dec 7, 2007 9:15 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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?
>
> OK I tried the following:
>
> mvn -Prelease release:perform
> -DconnectionUrl=scm:svn:
> https://svn.apache.org/repos/asf/commons/proper/commons-skin/tags/commons-skin-2
>
> but I still can't see where its gone (doesn't seem to be in
> m2-snapshot-repository or m2-ibiblio-rsync-repository) and logs seem
> to indicate its being uploaded to "dummy" - any ideas?
>
> 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
>
>
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 7, 2007 9:15 PM, Niall Pemberton <ni...@gmail.com> wrote:
> On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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?
OK I tried the following:
mvn -Prelease release:perform
-DconnectionUrl=scm:svn:https://svn.apache.org/repos/asf/commons/proper/commons-skin/tags/commons-skin-2
but I still can't see where its gone (doesn't seem to be in
m2-snapshot-repository or m2-ibiblio-rsync-repository) and logs seem
to indicate its being uploaded to "dummy" - any ideas?
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
Re: [all] m2 release process
Posted by Niall Pemberton <ni...@gmail.com>.
On Dec 7, 2007 9:01 PM, Dennis Lundberg <de...@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?
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
Re: [all] m2 release process
Posted by Dennis Lundberg <de...@apache.org>.
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
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