It isn't always a bad thing to just check in changes no matter what. I mean you still benefit from Maven's versioning so if you find yourself barking up the wrong tree with a bunch of bad commits, your users will still be happy using the stable or earlier versions of your code. The nice thing about Maven is that to get something deployed, even snapshots, it must compile and pass tests too. If anything Maven makes using source code repositories even easier because it decouples the requirement of making sure the build ALWAYS works from the source repository and other projects using the outputting artifact. Essentially Maven fills in the missing "artifact repository" that developers have always needed.
Ravi On 5/15/07, Siegmann Daniel, NY <[EMAIL PROTECTED]> wrote:
<<Thanks for the answer. So you think the best way is to let developers commit manually and use the integration Server to make the builds once the SCM repository has change and inform in case of error?>> I expect that your developers will sometimes wish to run the unit tests without committing the changes. Therefore having the commit be automatic is undesirable. Heck, I have occasionally deployed a snapshot from my machine before committing changes. If you want to commit after running tests, just execute "mvn test scm:checkin". However, I am strongly of the believe that developers should test changes on their own machine before committing to the repository. Having CI does not make it OK to break the build! CI simply allows mistakes to be caught sooner rather than later (probably the most common IME is forgetting to add files to the repository before committing). -- Daniel Siegmann FJA-US, Inc. 512 Seventh Ave., New York, NY 10018 (212) 840-2618 ext. 139 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
