Gradle as well as Maven are build automation tools. Both are built upon plugins, both manage dependencies, both can build your project and push build artifacts to an artifact repository.
So why should you choose Gradle over Maven?
Gradle offers several geat features like Incremental Builds and a Remote Build Cache to boost the performance. With incremental builds you don’t need to build everything. If only a small part changed, just this little part needs to be rebuilt and of course the parts that depends on.
Gradle goes even a step further, you don’t need to build at all if someone else already did it. If the CI-System already did a build run and published the outputs on a Build Cache Node, Gradle will just download them instead of running the whole build. Another point is the powerful extensibility, but the most significant reason to go for gralde is the dependency management.
Dependency Management
One of the more interesting points in dependency management is the determination of versions of transitive dependencies. Gradle uses the highest version of a dependency that can be found in the dependency tree. On the other hand Maven uses the version with the shortest dependency path.
But what happens if there's a dependency muliple times in the project with different versions and both have same dependency path length? Here’s an example:
Two Modules A and B pull the same library commons-io
with different versions (2.11.0 and respectively 2.5) and a Main Module having Module A and B as dependency
Running the dependency:tree
goal on the MainModule gives us following result:
MainModule pulled commons-io:2.5
through Module A. You can probably already guess it: it’s the order in the pom.xml
.
Let’s swap it in the MainModule.
And run the maven goal again.
So the order of dependencies in the pom.xml
is relevant. Imagine changing the order just to group some dependencies and therefore switching to an older version of another dependency with a bug you didn’t even think about. It’s probably a very rare case, however I’d prefer having the newest version anyway.
Another big point is the power of dependency management in Gradle. One example is the distinction between producer and consumer. If you’re creating a library and therefore taking the role of a producer, you can choose whether you pass your dependencies to the consumer. Furthermore Gradle supports concepts like Feature Variants or Component Capabilities. All in all you have more control over your dependencies and that’s what dependency management is all about, especially if you’re working on a project with over 50 or 100 modules (respectively “subprojects” in Gradle).
If you’re coming from a Maven background and want to try out Gradle without reading too much docs, I’d highly recommend you this section.