On Oct 7, 2008, at 6:45 AM, Guillaume Laforge wrote:

I don't know Guillaume if you ever had to create and maintain a Maven 2 build. I was the build master for two very complex Maven 2 enterprise builds and I can only warn anybody of using this tool. Rather stick with Ant.

Kudos for Maven for introducing the concept of build-by-convention long before it was made popular by rails-like frameworks. If it wouldn't have been for Jelly, the Maven people might have sticked with their Maven 1 approach which I definitely prefer to what they provide with Maven2.

What is the problem with Maven2?

- It has the same problem as Ant regarding the anemic interaction with Java/Groovy (Maven considers this as a feature). The GMaven plugin does not make a difference here. You can't use Groovy to choreograph the build. - Maven enforces an often bizarre level of indirection (has anybody ever used the Maven constraint plugin to express the most simple custom constraint). Maven's verbosity is extreme. - Maven's dependency management is far inferior to Ivy. - Maven also introduces its own general purpose elements which are not necessarily implemented well (e.g. pom inheritance). (Have you ever tried to use a single property as a version value for all subprojects in a slightly complex multi-project build) - Maven is not based on dependency based programming. What it offers instead to hook in actions is significantly more inflexible. - Its multi-project build features are inferior to what Gradle offers. For example: -- You can't do partial builds. In Gradle you can build a subproject in a way that all the project it depends on are rebuild as well. In Maven you always have to trigger the complete build (and if this takes some time you have to watch the console to push Ctrl-C when the stuff you want to have rebuild is done). -- Maven has not a distinct configuration and runtime dependencies between projects. For example if you want to configure the common stuff of a set of subprojects in a parent pom, this parent pom needs always to be build before the subprojects. Therefore you can't use this parent pom for example for creating an ueberarchive from the subprojects. You have to refactor the commons stuff in an artifical subproject with a pom the other subprojects inherit from. Such things makes Maven builds so hard to maintain and comprehend.

The biggest problem Maven has, is a conceptual one though. Erich Gamme has coined the phrase Frameworkitis for this kind of problems. He gave the following definition:

"Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don't want but you can't change it. It's fun to get all this functionality for free, but it hurts when the free functionality gets in the way. But you are now tied into the framework. To get the desired behavior you start to fight against the framework. And at this point you often start to lose, because it's difficult to bend the framework in a direction it didn't anticipate. Toolkits do not attempt to take control for you and they therefore do not suffer from frameworkitis."

He has also described the solution:

"Because the bigger the framework becomes, the greater the chances that it will want to do too much, the bigger the learning curves become, and the more difficult it becomes to maintain it. If you really want to take the risk of doing frameworks, you want to have small and focused frameworks that you can also probably make optional. If you really want to, you can use the framework, but you can also use the toolkit. That's a good position that avoids this frameworkitis problem, where you get really frustrated because you have to use the framework. Ideally I'd like to have a toolbox of smaller frameworks where I can pick and choose, so that I can pay the framework costs as I go."

This is one driving vision of Gradle. Offer build by convention but avoid frameworkitis. Offer little frameworks which cover the major use cases for this area. Offer toolsets (and after all a general purpose language) for all the stuff a build system will never be able to anticipate in the very complex problem space of project automation. And all this should be straight forward to use without unnecessary directions.

Only with an internal DSL you have the tool to use toolsets. And internal DSL's are a major selling point for Groovy, and this with good reason. Therefore for me it would be kind of ironic if Groovy would use Maven as its build system.

- Hans