On Dec 10, 2007 9:07 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > Niall Pemberton wrote: > > 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. > > 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: [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]
