What matters in a build tool is efficiency

After reading Maven or Ant, which you’d be better off skipping because it’s full of nonsense, I decided to take a quick look at Gradle and see whether it might offer something Maven didn’t … Right on the homepage I read that it was essentially Ant wrapped in Groovy, with dependency management handled by Ivy or Maven. To cut it short, after skimming the Gradle user guide I happily closed the browser and told myself this was definitely not the way for me.

Gradle will surely be a great system, but it doesn’t meet one basic need, at least for me. I don’t know if you see it differently, but what I want most from a build system (let’s reduce Ant, Maven, Gradle, Gant, and the others to that term) is efficiency, measured by how much I get out for what I put in.

What I mean is that my use cases boil down to creating a project, compiling it, running the tests, building the package, and opening the project in the IDE. Full stop. Do we really need anything else? I’ll leave the answer to you. The more simply a build system can meet these use cases relative to what I have to do myself, the more efficient it is for me.

So far Maven gives me the most efficiency. Creating a project from an archetype alone takes half a minute. The other use cases follow from that. By contrast, systems like Gradle or Ant force me to do something I can’t stand: program my own build. When will the authors of these systems realize that their users don’t want to solve problems like having to specify compilation, packaging, and so on somewhere? Programming is just one way to specify them. Users simply want to use the system.

That’s why I like Maven so much. Its authors understood that for ordinary development use, the effort involved should be as close to zero as possible. That’s apart from reading the how-to or documentation, of course, which you have to do when starting with any new technology.