Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of niall.pemberton@gmail.com
 designates 64.233.184.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gRCMNJMQHziiBDyk3MXnd63BtaYLG8AWCUIYesa5tS4uZME5zy//kTVv0iJyWBUbTdnjqJ4T22hLHkrBFrGyAqd8i+1Q34JM7j3dJBpSTLCFAOvT2/kT6dmwKsiCnuScjqeLlabkA/CmrmwH/mY3feKe+ReXmGveqYBj+2o92m8=
Message-ID: <55afdc850712101828t3725eb33w85242d1e8a05dfac@mail.gmail.com>
Date: Tue, 11 Dec 2007 02:28:24 +0000
From: "Niall Pemberton" <niall.pemberton@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [all] m2 release process
In-Reply-To: <475DAA82.6050009@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <55afdc850712071058pef7e8d7tec6f5f4a7467b37@mail.gmail.com>
	 <55afdc850712071551n1b4b8fb3u74504a7dec71d964@mail.gmail.com>
	 <475BE2B6.9020901@apache.org>
	 <55afdc850712090518h6f9d0bd8s2d5e7da167e03896@mail.gmail.com>
	 <475BF041.9070804@apache.org>
	 <55afdc850712090611v21596bc6wdf9e817d00f524a0@mail.gmail.com>
	 <475BFB56.3020408@apache.org>
	 <55afdc850712091502k793e7b5dn52b31f63eca3a03e@mail.gmail.com>
	 <55afdc850712091659p78634e83y7fbae1dbf2a06b6a@mail.gmail.com>
	 <475DAA82.6050009@apache.org>

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