[all] m2 release process

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[all] m2 release process

Niall Pemberton
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Ben Speakmon-3
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Dennis Lundberg-2
In reply to this post by Niall Pemberton
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Ben Speakmon-3
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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
In reply to this post by Dennis Lundberg-2
On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Dennis Lundberg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
On Dec 7, 2007 9:15 PM, Niall Pemberton <[hidden email]> wrote:

> On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Dennis Lundberg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Ben Speakmon-3
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 <[hidden email]> wrote:

> On Dec 7, 2007 9:15 PM, Niall Pemberton <[hidden email]> wrote:
> > On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > >
> > > --
> > > Dennis Lundberg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
On Dec 7, 2007 9:31 PM, Ben Speakmon <[hidden email]> 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 <[hidden email]> wrote:
>
> > On Dec 7, 2007 9:15 PM, Niall Pemberton <[hidden email]> wrote:
> > > On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Dennis Lundberg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Dennis Lundberg-2
In reply to this post by Niall Pemberton
Niall Pemberton wrote:

> On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Dennis Lundberg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
On Dec 7, 2007 11:32 PM, Dennis Lundberg <[hidden email]> wrote:

> Niall Pemberton wrote:
> > On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >> --
> >> Dennis Lundberg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
On Dec 7, 2007 11:51 PM, Niall Pemberton <[hidden email]> wrote:

>
> On Dec 7, 2007 11:32 PM, Dennis Lundberg <[hidden email]> wrote:
> > Niall Pemberton wrote:
> > > On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
> > >>> For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>
> > >> --
> > >> Dennis Lundberg
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Dennis Lundberg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Wendy Smoak
In reply to this post by Dennis Lundberg-2
On Dec 7, 2007 4:32 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Rahul Akolkar
In reply to this post by Niall Pemberton
On 12/7/07, Niall Pemberton <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Rahul Akolkar
In reply to this post by Dennis Lundberg-2
On 12/7/07, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
In reply to this post by Rahul Akolkar
On Dec 8, 2007 4:00 PM, Rahul Akolkar <[hidden email]> wrote:
> On 12/7/07, Niall Pemberton <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Niall Pemberton
In reply to this post by Rahul Akolkar
On Dec 8, 2007 4:06 PM, Rahul Akolkar <[hidden email]> wrote:

> On 12/7/07, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Dennis Lundberg-2
In reply to this post by Niall Pemberton
Niall Pemberton wrote:

> On Dec 7, 2007 11:32 PM, Dennis Lundberg <[hidden email]> wrote:
>> Niall Pemberton wrote:
>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>> --
>>>> Dennis Lundberg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Dennis Lundberg-2
In reply to this post by Niall Pemberton
Niall Pemberton wrote:

> On Dec 7, 2007 11:51 PM, Niall Pemberton <[hidden email]> wrote:
>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <[hidden email]> wrote:
>>> Niall Pemberton wrote:
>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>> --
>>>>> Dennis Lundberg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Dennis Lundberg-2
In reply to this post by Rahul Akolkar
Rahul Akolkar wrote:
> On 12/7/07, Niall Pemberton <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] m2 release process

Dennis Lundberg-2
In reply to this post by Niall Pemberton
Niall Pemberton wrote:

> On Dec 8, 2007 4:06 PM, Rahul Akolkar <[hidden email]> wrote:
>> On 12/7/07, Dennis Lundberg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12