"... I am not comfortable enough with them to count on it working right every time."
That is not completely accurate. I discovered the checkpoints after learning (through trial and error) about the release plug-in. I can see in the code that they should work every time, but I did not know about them when I started. Not knowing about them at that time gave me the impression of a process that we not repeatable. Therefore, I am now in the habit of removing the properties file when the release:prepare does not end with a good result. It would be nice to take a look into the checkpoints, to see how they can help. Thank you, Michael I usually perform a synch or compare before executing the release:prepare. I agree that a failure or user abort during that goal is not transactional in nature. I know that checkpoints exist in the release.properties file, but I am not comfortable enough with them to count on it working right every time. I usually blow that file away and start over. On the bright side, once you can get through it, the process is nicer than the manual alternatives. Michael -----Original Message----- From: Patrick O'shea [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 10:05 AM To: Maven Users List Subject: RE: [m2]release:prepare requires snapshots ? Hi, Is there an issue with release:prepare when running against multiple projects ? I'm running this against a parent project with two child projects. When release:prepare runs from the parent project it runs correctly against the first child project and updates the version numbers in the poms to the new numbers. However because the second child project has a reference to both the parent project (through <parent> tags) and a dependency on the first child project it will fail the cvs diff that is part of the release:prepare. This is because during the execution of the release:prepare on the first child, it modified the second childs pom.xml with the new version numbers and didn't check second project pom.xml. Has anyone else managed to sucessfully perform a release:prepare under similar conditions ? thanks patrick "Mike Perham" <[EMAIL PROTECTED]> 01/04/2006 03:48 PM Please respond to "Maven Users List" <users@maven.apache.org> To "Maven Users List" <users@maven.apache.org> cc Subject RE: [m2]release:prepare requires snapshots ? I think the idea is that if you are releasing an entire set of projects at once, you would want to keep their versions in sync. If you want to do what you say below (which is what we want to do also), you just do finer grained releases. You don't do recursive releases but only release those modules which have changed. mike -----Original Message----- From: Laurent Berteau [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 5:06 AM To: Maven Users List Subject: Re: [m2]release:prepare requires snapshots ? Hi, dan tran wrote: > It follows maven development process where > > - during development, every one works on snapshots > > - at release time, the snapshost got changed to release version, > check back into SCM, label, and build. > This is where customer can use, including qa, stake holder, etc > > - then the version is increamented with snapshot and check into SCM again. This implies that in a multi-module project, every sub-module version number is incremented even if no changes has been made. I have a multi-module project where some modules do not evolve frequentely whereas some do. I do not want to overload the repository and the scm history with different version of exactly the same code. Is the only solution to run the release plugin against each module independently ? Do my way of thinking does not fit with the maven approach of the release policy ? Best regards, -- Laurent Berteau --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
