[...] I don't know Guillaume if you ever had to create and maintain a Maven 2

[...] 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.

[...] 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.