commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [all] m2 release process
Date Sun, 09 Dec 2007 23:02:58 GMT
On Dec 9, 2007 2:27 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Dec 9, 2007 1:40 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> >> Niall Pemberton wrote:
> >>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <dennisl@apache.org> wrote:
> >>>> Niall Pemberton wrote:
> >>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <dennisl@apache.org>
wrote:
> >>>>>> Niall Pemberton wrote:
> >>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <dennisl@apache.org>
wrote:
> >>>>>>>> For logging I followed the current release procedure
[1], which worked
> >>>>>>>> well. Sections 11 and 12 need to be merged somehow.
As I'm not familiar
> >>>>>>>> with releases back in the Jakarta days, I'm not quite
sure how to
> >>>>>>>> though. Other than that, it was obvious what to when
the docs talk about
> >>>>>>>> Maven 1 specifics. But that's probably just me, because
I'm used to
> >>>>>>>> doing releases with Maven 2 over in maven land. So this
needs to be
> >>>>>>>> written down.
> >>>>>>>>
> >>>>>>>> For releases support artifacts that reside only in the
Central repo
> >>>>>>>> (parent poms, skin) I have simply done:
> >>>>>>>> - vote based on svn revisions
> >>>>>>>> - mvn release:prepare
> >>>>>>>> - mvn -Prelease release:perform
> >>>>>>> OK I found this http://tinyurl.com/2h222s and was following
that. "mvn
> >>>>>>> release:prepare -Prc" works fine but the first time i did
"mvn
> >>>>>>> release:perform -Prc" (fogetting -Darguments="-Prc") and
I couldn't
> >>>>>>> find where it went and from the logs it looked like it uploaded
it to
> >>>>>>> "dummy" - so I undid the prepare and tried again with:
> >>>>>>>
> >>>>>>>    mvn release:perform -Prc -Darguments="-Prc"
> >>>>>>>
> >>>>>>> This time it threw a NullPointerException in the SurefirePlugin(line
594)
> >>>>>>>
> >>>>>>> So can I do "mvn -Prelease release:perform" without having
to revert
> >>>>>>> the version 2 tag? If so how?
> >>>>>> We seriously need to remove the "dummy" repo setting from the
parent
> >>>>>> pom. It does nothing but cause grief.
> >>>>>>
> >>>>>> If we remove it, calling 'mvn release:perform will copy the
artifacts to
> >>>>>> the snapshot repo if the version is a SNAPSHOT, and to the
> >>>>>> central-sync-repo if it's a "real" version. We have to trust
ourselves
> >>>>>> to call the right commands, not having to remember which non-standard
> >>>>>> command-line switch to add. Just use Maven the way it is.
> >>>>> OK but using -Prelease should override the deployment repository
and
> >>>>> when you do mvn help:effective-pom -Prelease everything looks good.
> >>>>> Seems that something though is still picking up that dummy repository
> >>>>> though and I'm guessing the -Darguments="-Prelease" that Torsten
> >>>>> mentions here http://tinyurl.com/2h222s  is perhaps something to
do
> >>>>> with that? But for me that causes the NPE in the surefire plugin!!!!
> >>>>> Which looks like these:
> >>>>>
> >>>>> http://jira.codehaus.org/browse/SUREFIRE-314
> >>>>> http://jira.codehaus.org/browse/SUREFIRE-300
> >>>>>
> >>>>> I even tried adding -Dmaven.test.skip=true but it still threw the
NPE.
> >>>>>
> >>>>> So is there a way round to resolve this with the situation as it
is or
> >>>>> does it need a commons-parent release first to remove the dummy
repo?
> >>>> I think these problems start if you forget to use the proper profile
in
> >>>> the first place, when doing 'mvn release:prepare'. After that you're
> >>>> toast no matter what options you throw at Maven on the command line.
> >>> I don't really understand this - are not both the profiles ("rc" and
> >>> "release") we have "proper profiles" - just with a different
> >>> distribution destination? I tried with both.
> >> Yes they are. What I think is needed with our current setup is to do:
> >>
> >> mvn -Prelease release:prepare
> >> mvn -Prelease release:perform
> >
> > That was what I tried to do first time - except using the "rc" profile
> > (and user and password options) and it appeared to try to deploy to
> > "dummy" - thats what seems like a bug in maven to me.
> >
> > The second time I tried the above using the "release" profile, but
> > with Torsten's suggestion (http://tinyurl.com/2h222s) of adding
> > -Darguments="-Prelease" - that gave the NPE. I don't know what passing
> > value "-Prelease" for "arguments" does (btw I also see in the commons
> > logging pom the maven-release-plugin has a configuration valeu of
> > "-Prelease" for "arguments") but I'm guessing its so that the deploy
> > bit picks up the correct profile and doesn't use the "dummy"
> > reposotiry specified in the commons-parent distribution voodoo?
>
> The release plugin calls other plugins during its run, amongst them the
> deploy plugin. The "arguments" is to pass that to the deploy plugin as
> you suspected.
>
> We might need to add a release-plugin configuration for this in a
> component or the parent. Need to play around with this a bit.

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


Mime
View raw message