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? > 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. > 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. 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]
