[...]

I hope this is not the general attitude of Groovy in regard to refactoring ;)

[...] For one there is a technological reason. The claim is that the Groovy build will be easier to maintain and that it is easier to push project automation a step further.

But there is another strong reason why I think Groovy should think about switching its build system. It is a strategic reason. There is a lot of movement in the build area at the moment. For me this is a clear indication that people are not happy with the choices they had until recently. There is the Ruby based buildr, which soon will graduate as an Apache project. There is the popular SCons based on Phyton which is trying to improve it Java build capabilities. And there is Gradle based on Groovy/Java (as Russel has pointed out, Gant's use case is different). My opinion is that build systems will soon become the most important reason after web frameworks, for Java developers to learn a dynamic language. Which dynamic language they will learn, depends on the choice of the build system. I think it is in the very interest of Groovy to do everything to push the momentum of a Groovy based build system that is capable of competing with the other ones mentioned above. I'm very confident that Gradle is able to compete anyway. I'm very happy with the feedback and adoption. But if a popular project like Groovy would say we are using Gradle that would definitely accelerate things.

Of course I have to close this mail with a phrase: This would be a win-win.