What I dislike at current build systems is that you often have no separation of concerns. You write helper in your project that then will be used by the build system, because the build system is not powerful enough to express it on its own. In ant you do this by writing ant tasks. For make in a C project you wrote helper in C. In m1 it was ant tasks too, or something with Jelly. In m2 it can be a plugin written in Java. I think the m2 idea is kind of the natural evolution here. In all these cases you either mix parts of your build logic into the normal project because of helper files not used by your project... or you go further and make a plugin like in m2, which needs to be compiled and deployed. This adds a level of indirection which is praised as the wonder weapon against problems, but I personally think of this as a perversions of an easy build. It is easy when the plugins do come from the outside, but the problem that I have to make leaps and somersaults just because my build system can't properly express what I need remains. In fact I reached the goal to separate my build logic from the build so much, that using this becomes a problem in itself.

Another problem of most build systems is that you have to breach media very often. In ant you program in XML... that in itself is something I think should be considered as a media breach... but most people then go and XSLT or write custom ant tasks. You use these, because the XML becomes unreasonably big if you do not do so, or things can be expressed more easy that way. Again the build system and the way of usage is to be considered as not powerful enough here. In make you often use autoconf... a joy in itself, but probably still better than many ant builds... only that autoconf doesn't help you much with java builds. In m1, well I mentioned the usage of jelly and ant tasks already. With the ant task you have not only a media breach, but also a breach in the build system usage... m1 was thought to be independent of ant, or not? And jelly... well let us better forget that chapter. Now in m2 you have your plugins and your XML, which is again a media breach. The only way for m2 to avoid this is to minimize the XML part and hope no custom plugin is required. But the standard answer from the m2 guys to all sorts of problems seems to be to write a plugin...

The third part of my thought is "don't look only at the easy things". Of course all build systems have certain use cases where they are very easy to use. You can use make without autoconf in some cases, you can have small and nice m1,m2 and ant builds files... but what if you have to leave the road they gave you? make isn't good at checking library version information or even if there is such a library... it simply isn't in its scope. So a layer on top was made, the configure script. make has other problems as well, but I don't want to write a book here ;) m1.. well I am not really sure what was right or wrong with it... saying it was simply broken looks so unfair... but I am sure many will see it the same. I think ant is not really bad, it just grows too much and becomes unmaintainable then. Sure you have the media breach, but at last the so generated tasks are very easy to use. In m2 they tried to make it all better by conventions and restrictions. In fact so many of them, that they loose the easy usage part like ant has it and like they still had it in m1.

Probably part 2 and three can be condensed in "ease of use". Once you leave the road, there is no longer the question for a comfortable way, but how many walls you have to climb. Of course many m2 people will argue, that if you organize your source according to their pattern and that if you use the plugins the m2 world gave you, you have no really big problems - besides bugs in the plugins. But what if there are reasons to not to follow the m2 conventions? I think it is just too easy to say that if you don't follow the conventions you have to live with the difficulties. A good build system should instead still try to support them as good as possible and not add new walls he has to climb.

Now I personally dislike XML. For me XML stands for "cross machine language" meaning it is not intended to be used by the human reader.

Also If you need a GUI or even IDE to just get things rolling then some things are wrong. I mention those because often it is said you can have a special editor with auto-completion and which validates the XML and whatever... as I said... if I need those, then something is wrong. Also once you have to program in XML something is really wrong.

I think a build system can be most powerful if it is based on a programming language, allowing you to write tasks/plugins without media breach. Where you can hook into the build logic itself to bend it to do your non standard things... maybe even making a more or less new build system out of it, if you need that. So instead of avoiding logic in the build file, the build file should consist of build logic. That is completely against the ideas in maven. But most people using build files are more or less good programmers and why should this potential power not be used?

For example the question should not be how good the build system does multi project builds, instead the question should be about what I have to do to et my build system to support multi project builds in the way I want to have them! The question shouldn't be if the dependency management of ivy or maven is better, instead the question should be what I have to do to use either of them. A build system should not work against your personal taste of what tools you have to use and what layout should be used. Instead a build system should give support to make the non standard things easy too. And so on.

And I think a programming language to program/configure the build is what is needed to get this working.

I am not sure if gradle can already achieve all these goals already or if it even intends to do so, but I think gradle is more near to this ideal than ant or maven.

So what technical reasons to switch or not to switch can I extract from these for a build of Groovy? In fact I failed in my explanation at a very important point. That point is why? Why want I have such a flexible system? Nad my simple answer would be maintainability. If you don't need to change your build anymore, then any build system is fine, because as long as you don't have to touch the build files any build system will do. Never change a running system... But once you have to extend your build you already reached the point where your current build doesn't do the job anymore. And again it does not matter what build system it is, the build wil be more complex in the end. So the cost factor is the thing that has to be reduced. How much can I change the build without increasing the complexity of the build too much? Often people tend to not to extend the build any further, because it is already too big and nobody actually understands it anymore. It starts with a decreasing number of people who actually know what the build does and ends with people just trying and guessing. Several refactorings may help to ease the pain, but the comlexity will grow without mercy.

I think that ant has a bad cost factor here. It does not take much for the build to be too complex. And I think for Groovy we already reached the point where just one or two actually know what the build does. At times of m1 I understood the build more or less, but from my point of view the current build is at last as complex as the m1 build now... and I fail to understand it anymore.. to many strange fork calls are in there for me. so each change will brings us to the point where noone actually understand the build anymore... and I don't think that the current build will be sufficient for whatever we do in Groovy in the future. For example I would like to automate the upload of the files. I would like it to handle connection problems and other stuff. But I don't dare to write something for ant. So from my point of view we already reached the point where we do certain things not anymore, because it is too complicated.

And I doubt m2 will help me with all the non standard things I would like to do. So a switch to gradle seems to be the right thing for me.