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.

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?

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.

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.