Lets get one thing out of the way, declaring dependencies like this:
is waaaaay better than declaring them like this:
This is where the positives for Gradle end.
First off, you cannot not learn Maven. The entire Java world is built using Maven conventions. Every artifact published on Maven Central has a maven
pom.xml file. So using Gradle means you learn both Maven and Gradle.
Learning Gradle also means that you have to understand Groovy at some level, to understand how your build script is being composed. But Gradle adds it own DSL to the mix making it impossible to decipher what Groovy language constructs are being used for a particular line in a Gradle script. For example, one can't just define a global variable and use it in the script. Instead it has to be in an
We don't need the advanced features
Astradot's Java projects are small microservices. All we need from a build tool is to download dependencies, compile, jar and run a few basic tests. All the advanced, mindbending, quantum-entangling caching features that Gradle has are simply not needed.
Maven is old and robust. All editors understand it. Intellij's support for it is flawless. The XML while verbose is easily understood.
There is an exception though...
Wait, there actually is a place we use Gradle. That is for our Java Tracing Agent. The requirements for putting together the agent are not like your typical Java jar. Neither Maven nor Gradle could build it out of the box. Our initial thinking was to write a custom build tool for it. However, this is where we found that Gradle absolutely shines. Doing a completely custom build, where you are taking full advantage of the dynamism of having groovy as a full-fledged programming language as opposed to just a declaration format made Gradle the perfect tool for the job.
For everything else, we saw no reason to choose Gradle over Maven. We do miss those single-line dependency declarations though.