Maven vs Gradle – One Year Later

About this time last year I was faced with a decision to migrate the existing manual and IDE bound process of compiling our web application to a more modern build tool. Given that we were Java developers, there were two main contenders: Maven and Gradle. The $64,000 question was, which one?

This proved to be a more challenging question that I first imagined.

I had a reasonable amount of experience with Maven in previous projects. It had proven itself to be reliable, and given its long history and widespread adoption, migrating to Maven was almost the default option.

Gradle was still something of a newcomer, having only reached version 1.0 in 2012. But there was a lot of excitement and support for this new project, and some big names had already made the switch from Maven to Gradle.

Without much personal experience to base a comparison between the two options, I went online and tried to compile a list of pros and cons for each. To be honest, it was very hard to find objective comparisons between the two. The 2013 Thoughtworks technology radar provided some advice:

Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex.

Some large projects like Hibernate provided comparisons between the two tools, as well as a blog post explaining the move to Gradle. Android was another notable project that had adopted Gradle to build their code.

For all the online discussions arguing one way or the other, it appeared that both Maven and Gradle provided all the functionality we needed. Both were supported by our IDE, both could build the kinds of projects we needed, and in reality we were only really talking a few dozen lines of XML/Groovy regardless of which option was chosen.

Without a clear winner I decided to take Thoughtworks advice and standardise on Gradle.

That was a year ago. So how did the decision play out? First, let's start with the bad.

IDE support for Gradle was still pretty raw. It was not uncommon for developers to have to run through an inconvenient process of refreshing and rebuilding projects in Eclipse when the IDE tooling failed. It was frustrating, and it was something that I had never experienced with Maven.

Debugging issues with Gradle was also more time consuming than it would have been with Maven. Sites like StackOverflow have covered just about every possible situation you are likely to run into with Maven, but the same could not be said for Gradle. Often I found myself having to trawl through rambling forum posts and message lists to gain some insight into a bug or issue.

Gradle plugins are still quite immature. It was not uncommon to find that the Gradle equivalent to a stable and popular Maven plugin was only at version 0.1. Gradle just hasn’t had the years that it takes for this kind of ecosystem to build up and stabilize.

Finally, Gradle is still documented by a lot of libraries as “that other build tool”. I have never yet seen an example where documentation for Gradle surpasses that of Maven for third party plugins or libraries.

Fortunately though, in our case the good has outweighed the bad.

One of our projects based heavily on Camel was migrated to a mix of Java and Groovy to make use of custom DSL extensions. Gradle made this migration seamless with its excellent support for joint compilation. Had we been using Maven, I expect it would not have been as easy to adopt Groovy into our project.

Gradle’s native support for wrappers proved to be very handy. A Gradle wrapper is like a small stub application that you check into your VCS along with your code. If someone needs to build that application, all they need to do is run “./gradlew build”. If they don’t have a local copy of Gradle, it is downloaded and installed. This saved me weeks of dealing with IT to get a new application installed on our developers PCs, because I could essentially distribute Gradle with the source code of our applications. It also means that I can be sure that anyone can rebuild our applications, without having to worry about them already having the correct version of Gradle installed.

As it turns out, the flaky nature of the IDE tooling has largely been resolved. I think it is safe to say that today all major IDEs have quite good support for Gradle. I haven’t had any issues in IntelliJ, and those using Eclipse haven’t reported nearly the same level of frustration that we experienced a year ago.

But I think the biggest benefit of migrating to Gradle was found as the complexity of the projects that we needed to build increased. We went from having one kind of project to build (essentially a stock standard WAR file) to now having at least 4 distinct build profiles (WAR files, JAR files, Groovy based projects, and JavaScript based web applications). Gradle allowed us to manage the similarities and differences between these builds with the same kind of mentality that we would apply to a business object. Groovy is a very flexible language, and because Gradle is Groovy, isolating these differences behind interfaces and implementing them with classes or traits turned out to be a very natural thing to do for an existing Java developer.

In the end I believe that the decision to select Gradle over Maven was the correct one. This is by no means a criticism of Maven, which is still an excellent tool, and will be the best tool for the job for many. But for us it really did turn out that fine-grained abstraction and flexibility of Gradle build scripts was incredibly beneficial as the complexity of our code base increased. And while these benefits become increasingly more valuable over time, the negatives I associated with Gradle, namely the immaturity of plugins and the lack of community support, will diminish.

The choice between Maven and Gradle is still not an easy one to make, because both are very capable tools. But hopefully my experience will give someone just that little bit more information than I had when making the decision.