On Mon, May 7, 2007 6:24 pm, Peter Kahn wrote: > How does maven's declarative convention over configuration stack up > against scripted solutions like buildr, groovy/ant or scons when it > comes to maintenance costs for large projects?
Scripted systems have an Achilles heel - build systems are not the primary task at hand in a large project, the code is. As a result scripted build systems are generally poorly designed and implemented, even though the tools on which they are built (like ant) are top notch quality. The scripted systems in every large project I've ever encountered were complex, incomprehensible, platform specific and incomplete, and ultimately thrown out. The standardisation efforts of maven save a fortune - in our case on a big project, releasing the project takes the form of "mvn release:prepare" and "mvn release:perform", and that is it. This means that any member of a project team can make a release, and that release will probably work first time, or fail for very clear and obvious reasons. > "how sustainable is maven for large scale projects" Implementing maven is not a walk in the park in a complex project. There are times when the classic maven design philosophy of "let maven figure this out for you" doesn't always hold true, meaning you have to understand enough about the build process to make sure things work together. Some of the maven plugins are not as reliable, or as complete than others. But - having implemented a maven build system, all the maven features, from release management, to documentation management, come for free. This investment in standardisation pays big dividends in the future. In short, the bigger the project, the more useful maven becomes. Regards, Graham -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
