On Dec 9, 2007 11:02 PM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > 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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
