Hi, Maven 2 provides a well defined and excellent build process. If the code basis is organized according to the Maven default project layout Maven can do amazing things without almost no configuration.
The documentation is improved and there is a free PDF document available: http://www.mergere.com/m2book_download.jsp I am using Maven 2 now for almost 18 months with excellent results. The learning curve is a little bit steep but it is worth the effort. Before that I was using Maven 1 for two years and I happily switched to it from Ant which I started to use in 2000. Ant is very powerful but what really attracts me to Maven is the paradigm convention over configuration and the powerful dependency management. Maven per default tries to locate unit tests and executes them as part of the build process. It will fail if unit tests fail (unless otherwise configured). I think that a release cannot happen if builds fail. If a contribution fails with its unit tests it should not be part of the release. Just my 2 cents. Andreas On 5/17/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
I like what Paul said here. I was thinking the same about "unmaintained" contribs. Otis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simpy -- http://www.simpy.com/ - Tag - Search - Share ----- Original Message ---- From: Paul Elschot <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Thursday, May 17, 2007 3:51:14 AM Subject: Re: Tests, Contribs, and Releases On Thursday 17 May 2007 09:10, Chris Hostetter wrote: ... > It could be argued that contribs are not important enough for contrib test > failures to result in a nightly build failing (I have no strong opinion > about this). It could also be argued that while it's good to run test > against the "core" on a regular basis (ie: in the nightly), test failures > should not in and of themselves block a release -- so the ReleaseTodo > doesn't need to include any mention of running tests (I would argue > against this position very strongly) > I'd rather have a few tests too many, which means that I would prefer to have the contribs tested by default, and at least before a new release. Contribs depend on the core, and their tests might also indicate a problem in the core, even though that is not their intention. When a contrib fails and is not fixed, that might be a good reason to remove it from the distribution. With such a policy the present contribs would also stay up to date, provided their tests are good enough. Thinking about it a bit more, there is a process to add contribs, but there is not really a process to remove them. The policy of removing a contrib before a release when its unit tests fail could make a nice fit for that. Regards, Paul Elschot --------------------------------------------------------------------- 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]
