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.

- 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."