What's in a Build Tool?

Properly done autoconf is very developer-friendly for building but if you have to maintain it, it can be a nightmare.

OTOH, because you can always escape to shell scripts, I usually can fix any issue that crops up.

With cmake, I regularly fail, e.g. configuring succeeds but building fails because of a missing library and because I actually have no clue what the standard approach should be (online documentation is abysmal with cmake).

tl;dr: Maven is the exact opposite of flexible.

My personal opinion after managing the build system of a fairly complex java project for years, I'm glad we skipped Maven in the evolution. For me the most important part was error messages, and the most helpful were Ant > Gradle > Maven. We had very different conventions than what Maven offered, and shaping it to our process was cumbersome. Coupled with Maven 2.x and 3.x never played nicely together (at least for me), now when I see a Maven build I just sigh (looking at you Atlassian)

Finally, strictly personal observation, but Ant/Maven tend to correlate with SVN (or older VCS) usage, which you can argue still does its job, but is pretty much considered obsolete.

[1] https://www.thoughtworks.com/radar/a-z#gradle

There are a few advantages even for simple projects, though:

* I really like Gradle's wrapper feature, which means you can check in a small bootstrapper which downloads Gradle when you need it. That means you don't have to worry about installing the build tool, nor making sure you have the right version. It makes projects self-contained.

* Gradle caches downloaded dependencies in a directory which is distinct from your local repository. Maven just drops things into the local repository. To me, what Maven does is a fundamental confusion of purposes, and it makes it a headache to clean the cache, because you have no idea what is cached, and what is an irreplaceable locally-built artifact. Conversely, it makes it tough to look at your repository and work out what is an official artifact that came from the internet, and what is some crummy local thing you shouldn't rely on.

* Gradle knows about dependencies between tasks, and between tasks and files. When you run a build, Gradle can be fairly smart about what tasks it runs. If you're tweaking the packaging step, re-running the build won't run compile and test if the code hasn't changed. If you just want to run functional tests, tell Gradle, and it will re-compile if necessary, but won't unnecessarily run the unit tests. Doing this with Maven involves manually working out what phases are necessary for what you want to do, and then listing them all on the command line.

Gradle starts to pull ahead significantly for large projects, though. In those, you inevitably need to do more complicated things - code generation, running special tools, multiple kinds of tests, including extra bits and bobs in the packaging, etc. For those, Maven rapidly becomes painful, whereas Gradle's difficulty scales no more than linearly with the challenge.

On the flip side, there's no significant downside to Gradle itself. It's perhaps fractionally slower. It opens the door to writing loads of Groovy code and making your build a nightmare, but there's a simple way to avoid that - just don't do it. You never need to write full-blown code to do anything you could do in XML in Maven; you only need to write code where you would also need to do so in Maven, as a plugin.

And when that does happen, you'll find that writing plugins is also much, much nicer with Gradle than with Maven, and there are really lightweight ways to start - you can write new task definitions right in your build script (which is not nightmare-inducing, because they work inside the normal Gradle flow), then move them out to external modules as you wish.

I'd suggest giving Gradle a go on a small project, one where you don't anticipate a lot of build complexity, just to get a feel for it.