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 Tue, 11 Dec 2007 02:28:24 GMT
On Dec 10, 2007 9:07 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>
> Niall Pemberton wrote:
> > 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.
>
> 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


Mime
View raw message