10 reasons to use Gradle instead of Maven
They’re tools to automate the build and they’re great. In this article I’ll give 10 reasons to start to use Gradle.
Before starting off with this title I tried this one “10 reasons to use Maven instead of Gradle”, but when I started my research, I discovered more opposite benefits.
TL;DR
The reasons are: Flexibility, Performance, UX, Support, Dependency Management, Non XML, Less code, Plugin Integration, Code reuse, and easy customisation.
Too long, read 📕
Reasons
1. Flexibility
Custom builds would be easy to do on Gradle. However, because Gradle is virtually a newcomer, the number of developers who know Gradle inside-out might be limited. [Stackify]
Google chose Gradle as the official build tool for Android; not because build scripts are code, but because Gradle is modeled in a way that is extensible in the most fundamental ways. Gradle’s model also allows it to be used for native development with C/C++ and can be expanded to cover any ecosystem. For example, Gradle is designed with embedding in mind using its Tooling API. [Gradle]
Both Gradle and Maven provide convention over configuration. However, Maven provides a very rigid model that makes customization tedious and sometimes impossible. While this can make it easier to understand any given Maven build, as long as you don’t have any special requirements, it also makes it unsuitable for many automation problems. Gradle, on the other hand, is built with an empowered and responsible user in mind. [Gradle]
2. Performance
Improving build time is one of the most direct ways to ship faster. Both Gradle and Maven employ some form of parallel project building and parallel dependency resolution. The biggest differences are Gradle’s mechanisms for work avoidance and incrementality. The top 3 features that make Gradle much faster than Maven are:
- Incrementality — Gradle avoids work by tracking input and output of tasks and only running what is necessary, and only processing files that changed when possible.
- Build Cache — Reuses the build outputs of any other Gradle build with the same inputs, including between machines.
- Gradle Daemon — A long-lived process that keeps build information “hot” in memory.
These and more performance features make Gradle at least twice as fast for nearly every scenario (100x faster for large builds using the build cache) in this Gradle vs Maven performance comparison.
3. User Experience
Maven’s longer tenure means that its support through IDEs is better for many users. Gradle’s IDE support continues to improve quickly, however. For example, Gradle now has a Kotlin-based DSL that provides a much better IDE experience. The Gradle team is working with IDE-makers to make editing support much better — stay tunedfor updates.[Gradle]
Although IDEs are important, a large number of users prefer to execute build operations through a command-line interface. Gradle provides a modern CLI that has discoverability features like `gradle tasks`, as well as improved logging and command-line completion.[Gradle]
4. Ongoing support
For ongoing support with Maven it’s not obvious where to go. You cannot raise issues on the GitHub repository and the Slack channel is only for contributors.
For Gradle support you can ask questions on the Gradle forum, Gradle community Slack channel, or raise issues on the Gradle repository itself. You can also debug Gradle build scripts directly from your IDE to solve issues yourself. [Tom]
5. Dependency management
- The use of substitution rules for compatible libraries
- The use of ReplacedBy rules
- Better metadata resolution
- The ability to dynamically replace project dependencies with external ones, and vice versa [Stackify]
Both build systems provide built-in capability to resolve dependencies from configurable repositories. Both are able to cache dependencies locally and download them in parallel.
As a library consumer, Maven allows one to override a dependency, but only by version. Gradle provides customizable dependency selectionand substitution rules that can be declared once and handle unwanted dependencies project-wide. This substitution mechanism enables Gradle to build multiple source projects together to create composite builds.
Maven has few, built-in dependency scopes, which forces awkward module architectures in common scenarios like using test fixtures or code generation. There is no separation between unit and integration tests, for example. Gradle allows custom dependency scopes, which provides better-modeled and faster builds.
Maven dependency conflict resolution works with a shortest path, which is impacted by declaration ordering. Gradle does full conflict resolution, selecting the highest version of a dependency found in the graph. In addition, with Gradle you can declare versions as strictlywhich allows them to take precedence over transitive versions, allowing to downgrade a dependency.
As a library producer, Gradle allows producers to declare `api` and `implementation` dependencies to prevent unwanted libraries from leaking into the classpaths of consumers. Maven allows publishers to provide metadata through optional dependencies, but as documentation only. Gradle fully supports feature variants and optional dependencies. [Gradle]
6. non XML
Gradle chose a code based build script. This means you configure a build by calling methods using the Groovy language, rather than using XML tags.
But the Groovy language has been used in a way that makes the build script look more like a definition than a script.
While different people find different file formats easier to read, such a dramatic size difference has some clear benefits.[Tom]
7. Less code
It helps readability, so you can scan through a build file and get to the point faster.
In Gradle I can see all the dependencies at once, without scrolling through pages of XML. [Tom]
8. Plugin and integrations
Maven also supports a wide variety of build life-cycle steps and integrates seamlessly with third-party tools such as CI servers, code coverage plugins, and artifact repository systems, among others. As far as plugins go, there is a growing number of available plugins now, and there are large vendors that have Gradle-compatible plugins. However, there are still more available plugins for Maven compared to the number available for Gradle. [Stackify]
9. Promotes build core reuse (DRY)
Gradle encourages you to treat your build code like you would production code. Or in other words keeps it D-R-Y (Don’t Repeat Yourself).
Code reuse in Gradle happens on 3 different levels.
- build script
- project
- cross-project
Which level you choose depends on the amount of reuse you require.
In Maven there’s one level of reuse, cross-project, which is when you create a Maven plugin. While this is sometimes helpful, we don’t always want the overhead of maintaining a separate project, especially when the build logic applies to one project only. [Tom]
10. Easy customization
With Maven, you can easily define your project’s metadata and dependencies, but creating a highly customized build might be a nightmare for Maven users. The POM file can easily get bloated as your project grows and might as well be an unreadable XML file later on. [Stackify]
