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.
