Why I converted a Gradle project to Maven

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

November 7, 2017

It may sound quirky, but I had finally HAD IT with a project I manage: Spring Web Services. There were several aspects of the build file that kept getting in my way.

Well, I was about to embark upon a critical change from which Gradle pushed me over the edge. To the point that not only did I convert to Maven, but ALSO moved the reference documentation from DocBook to Asciidoctor.

So what’s wrong with Gradle?

I know this is controversial, but I have worked with many projects. On the Spring team, it’s a common paradigm that if you need either a feature or a bug fix applied to some aspect of the portfolio, you check it out and submit a patch.

The community embraces this, and sometimes, if you really need something, the fastest route is to do it yourself.

Spring Framework, Spring Security, Spring Cloud Stream, Spring Session, Spring Session MongoDB, Spring Data Commons, blah blah blah. Just a handful of the projects I have dipped my toe in, some more than others.

Many use Maven, many use Gradle. I don’t mind Gradle for the occasional patch request. But when it came to an up-and-coming switch Spring Web Services had to make, Gradle wasn’t going to cut it.

Spring Web Services was going to create a new major release. We had supported 2.4 for a couple years, and 3.0 was about to get launched. This was the version where I could bump up the minimum to Java 8, Spring Framework 5, and other key 3rd party libraries.

That wasn’t the tricky part. The fact that we had to maintain the 2.4 branch at the same time, meant I needed a simpler build model.

Gradle comes loaded with a programming model that lets you declare things, and then hook in extra code to tailor things. And that is the problem!

Declarative vs. programmatic

Maven has this pattern of declaring what you want, and it goes and carries it out. You declare things like:

  • Artifact coordinates
  • Dependencies
  • Plugins

Because people frequently need to adjust settings for different scenarios, Maven supports the concept of profiles.

Gradle starts with the concept of a declarative build system as well. You can also declare:

  • Artifact coordinates
  • Dependencies
  • Plugins

But guess what? No first class support for profiles. Most people say, “no problem! Just code it.” Gradle uses Groovy, so you can write a little glue code, and BAM you have the concept of profiles.

Why do I need profiles? To make backwards compatibility maintainable, I always test each patch against the latest GA release of Spring Framework, as well as the latest snapshot release and the next major version. Each of these, captured in a separate profile, allows me to command my CI server to run every single patch across multiple versions of Spring Framework/Spring Security, and verify I’m not breaking anything.

Gluing this together with Groovy code was okay when I maintained a single branch. But migrating into maintaining two branches (master for 3.0 stuff and 2.x for the 2.4 stuff), that frankly wasn’t going to cut it. You see, Maven profiles are supported inside IntelliJ IDEA, but some glue code that emulates the same concept in Gradle doesn’t work AT ALL. It drives me to use the command line when my IDE should be supporting me.

This isn’t the only thing I’ve seen Gradle come short on where one must write code in their build file.

Frankly, I don’t WANT to write code there. That’s what I was able to do with Ant, and Ant drives one to spend too much time in the build file. Gradle is by no means as bad as Ant, but it seems a tad ant-ish.

Anything else?

Since you asked, there is another irritant. Gradle has plugins and that is great. Except that the blocks they add to your build file are at the global level. That means any construct you spy with settings inside it doesn’t identify the plugin they came from. You want to debug some piece of the build? You can’t jump to the plugin’s docs. You must first rummage around Google to determine which plugin is at hand.

To drive my point home, I’ve checked out projects where the developer built a handful of custom gradle plugins. That’s nice and handy, but it raises the need for me to READ every single plugin to know what’s happening.

Frankly, I’d prefer a block of XML, where the coordinates of the plugin AND its configuration details are RIGHT THERE. Maven may not offer the same magic of codability, but I fear that feature is shadowed by lack of discoverability.

Why the hate?

Okay, I know that Gradle is pretty cool out there. Many have been driven over the cliff by Maven. But to be honest, I haven’t seen enough payoff to warrant sticking with Gradle.

Since I could be wrong, feel free to dive into the comments and give me your pluses and minuses about Gradle vs. Maven!


  1. Leonidas

    Nice Article Greg ! Ive had a small chat in the office regarding I should move my Appium/TestNG/Cucumber project to Gradle, but I need hard facts to see why is Gradle better for my case. Surely each framework has its benefits but I believe many people judge Maven as if nothing has changed the last 5 years for it . You agree?

  2. Peter Thomas

    Totally agree, especially how being “declarative” is a good thing when it comes to structure and behavior consistency across teams, environments, tools and IDE-s. I’m a big fan of the Spring Framework and the team behind it, but I think some of them are responsible for creating an anti-Maven sentiment, which seemed to originate in the days when the Grails team joined the Spring team IIRC: http://graemerocher.blogspot.in/2008/12/grails-maven-kiss-and-make-up-with.html

    Here’s a recent example of how Gradle works differently in IntelliJ but works fine on Eclipse: https://stackoverflow.com/q/46782342/143475

  3. Ronaldo

    I would like to expose my point of view, even knowing that I can be totally wrong. I am an enthusiastic java programmer, I do not profit coding. I learned to code too late and never worked on a company team. I had very little contact with ANT and I’ve learned MAVEN the minimum to meet project needs. And I’ve been fight my self to not need GRADLE, but it seems to me that a giant wave hit the JAVA community and violently wants to force everyone to use GRADLE. I do not think I should migrate, this way I am firm in the fight against GRADLE, but I do not know until when! I found this article because I am trying to convert a LIBGDX – GRADLE project to MAVEN, it is not easy. In fact I see a great movement against the OPENSORUCE community! Oracle rewriting how JAVA can be used, VAADIN with 3 versions in less than 2 years, JAVAFX difficult to follow, since GLUON has a license for students difficult to obtain, I see attacks against ECLIPSE in favor of INTELLIJ IDEA, android plugins outdated in ECLIPSE and nonexistent for NETBEANS. WHAT I DO NOT SEE IS REACTION, ECLIPSE.org threw in the towel, APACHE looks ananased, inert. What looks like still standing is OPENJDK. This is the pespective of a off the board guy!


Submit a Comment

Your email address will not be published. Required fields are marked *