Ryan, Actually, you can modify the pom during preparationGoals as that is precisely the stage where the pom can be modified because thee release plugin has just modified it and is building with the modified pom to validate that the modifications work.
Nicolas, Perhaps what is needed is another place to insert goals... I've already added "completionGoals" to help with CI (though I have still to spin a version of the release plugin with that parameter exposed) The idea being that you could, in the preparationGoals, specify a goal that would resolve the dependency ranges into concrete versions and then use the completionGoals to open up the ranges again. Your use-case is somewhat similar so maybe we need another hook-point... though the more hook points we add, the more complex things get. It would be nice if you could just use the existing hook points, but here goes... if we had an "initiationGoals" so that it would look a little something like: 1. Call initiationGoals 2. Validate for release 3. Modify pom to proposed release 4. Call preparationGoals 5. Commit release poms 6. Tag release 7. Modify pom to dev of next version 8. Call completionGoals 9. Commit next dev poms That would give you scope to do some of what you want to do... though you'd have to specify the initiationGoals as something like "versions:use-releases scm:commit" so that the validation would work. And yes, I'd be wary of doing one set of validation checks and then calling some postScmChecksInitiationGoals followed by the scmChecks... whatever about adding an initiationGoals (which smells a bit hacky), splitting the validation step in to two and adding another fork point in-between is a no-go to me. ARGH!!!! there is one issue there. Pom modification does not result in a re-read of the pom itself. So even if you did modify the pom in an initiationGoals you'd be scuppered anyway. Perhaps the best think to do is to use the invoker plugin, use a profile called "makeRelease" which has the defaultGoal of validate and bind your invoker plugin to that phase... in that case releasing for you would just be mvn -PmakeRelease that would run invoker which would run on the current pom using src/release/invoker.properties (or whatever you choose to call it) which would then specify in sequence the series of mvn invokations to fire) Hmmmm longer response than I had planned -Stephen On 4 March 2011 10:50, Ryan Connolly <[email protected]> wrote: > This is probably obvious but I think even if you were able to run the > version updates the release plugin will complain about having local > modifications. The updated pom would also need to be committed before the > m-release-p will be happy. > On Mar 4, 2011 5:33 AM, "nicolas de loof" <[email protected]> > wrote: > > Hi, > > > > My project has dependencies on various common components, that have their > > own release lifecycle > > To get quicker bug-fixes and features we used to get them as SNAPSHOT, > and > > when we plan a release we release first the commons, then the project. > > > > To do this, I need to upgrade my POM to switch snapshots to recent > released > > version, here is the workflow : > > > > * release common > > * upgrade POM to released commom > > * release the project > > > > I would like to automate the latest steps using > > versions:use-releases< > http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html> > > BUT using this one as a preparationGoal in release plugin fails, as the > > "Don't use SNAPSHOT" rule is checked by release plugin before the > > preparationGoal is executed. > > > > Do you have any suggestion on the way to do this ? > > Maybe I should create a Jira to change the release proces task order, so > > that the SNAPSHOT check occurs AFTER preparationGoal (makes sense to me, > but > > maybe this has some side-effects) > > > > Cheers, > > Nicolas >
