On Dec 9, 2007 2:27 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > Niall Pemberton wrote: > > On Dec 9, 2007 1:40 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >> Niall Pemberton wrote: > >>> On Dec 9, 2007 12:42 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >>>> Niall Pemberton wrote: > >>>>> On Dec 7, 2007 11:32 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >>>>>> Niall Pemberton wrote: > >>>>>>> On Dec 7, 2007 9:01 PM, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> -- > >> Dennis Lundberg > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
