Patrick, The other project executes the release plugin in batch mode so it just uses default values (it increments the last number in the build and chooses fairly sensible defaults for the other values).
I also thought about the nice tagging feature of the release plugin and realized that, since we're using SVN, the repository revision number is good enough for nightly builds. I plan to look for something (or write it if I can't find it) that gets a hold of the revision number after Cruise Control synchs the source. Shoving that in an artifact would be enough, I think. It would let me pull back everything in the relevant project for that revision and build it. It's not as thorough as the tagging / no snapshot policy of the release plugin but I think it is good enough for such common builds. Other SCM systems work differently (Perforce, I believe, keeps a unique number for each file and not a global revision number) so to get the same effect a tagging plugin would be required, either executed by Maven or by the CI tool you use. Incidentally, on my project, we need the build number from the output of the deploy plugin. As far as I could see, there was no way to get a hold of that so I wrote my own plugin that will read the remote repository metadata and extract the number from it, making it available as a project property to the rest of the build. Thanks for the info, Patrick. Anybody else out there care to share their thoughts? Kevan. -----Original Message----- From: Patrick Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 24, 2007 10:59 AM To: Maven Users List Subject: Re: Process Question Interestingly, my organization is trying to figure out the same issue at the moment. The big problem that I see with the 'mvn clean deploy' is that, while the build is numbered, you don't really have any way of reproducing that specific build. That is, the deploy plugin doesn't tag anything in your SCM system. So, even though your SNAPSHOT is unique by virtue of the fact you have a timestamped/numbered artifact, you really don't have a good way to "see" the differences between two uniquely numbered SNAPSHOT builds... maybe this isn't really important, I'm not sure. The nicest thing about a 'clean deploy' is what you brought up -- you can have SNAPSHOT dependencies, whereas in order to do a release, you must remove any such dependencies. This can be a huge undertaking if your project is sufficiently large. I think you are on the right track re: your assessment of the "right" way to use these two plugins. The release plugin is a weightier process -- doing it nightly seems overkill, IMO. Out of curiosity, are they doing the release manually? As far as I know, releasing is generally a somewhat manual process. There is interaction that has to occur with the user, such as determining the next version number, whereas a 'clean deploy' could be automated... Patrick On 1/24/07, Kevan Dunsmore < [EMAIL PROTECTED]> wrote: > > I'm trying to determine the "right" way to use Maven in our continuous > integration environment. Here's our basic process: > > > > 1. Code changes are made and checked in to SVN. > 2. Cruise Control detects the change and kicks off a build, > executing all the tests. This is a local build (maven clean install). > 3. Once a day, or on demand, CC kicks off a numbered build (maven > clean deploy). This numbered build is tested by QA. > > > > So much for the good; now for the bad: We have opposing camps. One camp > uses the deploy plugin as illustrated above. The other camp, on a > separate project, is executing the above process except that instead of > using the deploy plugin, they are using the release plugin. As far as I > can see, the use of the release plugin in step 3 goes against its > intent. The release plugin is meant for a release to a customer, not for > something that happens frequently like a nightly build. Further, the use > of the release plugin in this manner restricts the use of cross-project > libraries to released versions, since the release plugin enforces that > the pom does not depend on any snapshots. > > > > I'd like to get the thoughts of the group on this. I may be missing > something but I'd far rather use the deploy plugin for nightly builds > and the release plugin for packaging the application for release to our > customers. Am I wrong? > > > > Thanks, > Kevan. > > > > > > > > Kevan Dunsmore > > Senior Software Engineer > > SABRIX Inc > > t: 503.924.4908 > > f: 503.620.5756 > > > > > This e-mail message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information that is protected from disclosure. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all copies > of the original message and any attachments. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
