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 Mon, 10 Dec 2007 00:59:55 GMT
On Dec 9, 2007 11:02 PM, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>
> 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

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


Mime
View raw message