Why I Moved Back from Gradle to Maven

“Maven is old school” they said. “Use Gradle instead. It’s the future of building Java applications” they said. Sounds like something you don’t want to miss. So I tried Gradle in two real-world projects. In this post, I like to tell you about my experiences with Gradle and why I finally migrated back to Maven. It’s a story about enthusiasm and disillusionment.

Disclaimer and Target Group of this Post

This post aims at developers who are currently using Maven and are wondering if they should use Gradle instead. If you and your team are already familiar with Gradle and you are using it happily in practice for a while, you can definitely go on with Gradle. I won’t talk you into moving back to Maven. ;-)

And at the end, it’s also a matter of taste. You can read many blogs about this “Maven or Gradle?” topic and everybody tells you another story. Finally, you have to try out Gradle on your own and make up your own opinion .

TL;DR

For me, there is no best build tool. Both Maven and Gradle can be great or painful - depending on the project and team. There is only the right tool for the right job . And there is the personal taste.

Gradle is really powerful and flexible, but also complex, hard to learn and to cope if applied to real-world projects.

Advantages:

Great Flexibility. You can do everything within the build script as you write them with the full-fledged programming language Groovy.

Great Performance. Gradle does an awesome job in speeding up your builds with features like incremental builds, daemons and clustered builds.

Drawbacks:

Steep learning curve. Moreover, the whole team has to learn Gradle or you will be depending on the single Gradle ninja in your team.

The dynamic Groovy DSL and the heterogeneous plugin APIs will make you google everything.

Unexpected side-effects, behavior, and interdependencies between plugins. It often feels like magic.

Breaking changes in Gradle itself and plugins becoming incompatible.

As Groovy is dynamically typed, it’s really hard for IDEs to provide good and fast (!) tooling. Contrarily, parsing and interpreting Maven’s XML is dead simple.

New Gradle versions are often breaking existing plugins and the poor maintainer of this one-man-open-source-projects can’t keep up with this speed.

Make sure that you really need Gradle’s flexibility and performance.

Especially in a (micro)service architecture, many builds are straight-forward and small. So you don’t benefit much from Gradle’s advantages but you’ll have the drawbacks anyway.

Also, consider your development workflow. If you are compiling and running the tests and application inside the IDE most of the time and, therefore, rarely execute the build on your local machines, you don’t benefit that much from Gradle’s performance features. However, on the CI server, you are always running a clean and full build. Not much time to save here for most projects.

Be honest: Is Maven really a big pain point in your daily work?

Takeaway : Consider

the complexity and speed of your build,

the existing Gradle knowledge in your team and

your development workflow

to decide if the non-trivial investment into moving to Gradle is justified.

My Gradle Story at Spreadshirt

We have June 2017.

Gradle is definitely a popular technology in the Java community. More and more open-source projects are using it and it’s the defacto standard build tool for Android. It promises a shorter and compact DSL, flexibility and high performance. Sounds great! So I started to get familiar with Gradle, did some getting started tutorials and finally started to convert an existing project from Maven to Gradle. The build included the following aspects:

Retrieve artifacts from our own Nexus (Maven repository).

Compile a Vaadin theme (mainly SASS). Integrate this seamlessly with the Spring Boot project layout.

Compile Kotlin

Read from the local Git repository and write the information to a version.properties which in turn is read by the application to create a /version endpoint.

Start a MySQL Docker container, run the tests and stop the container afterward.

Create a Spring Boot fat jar.

Upload the jar to our Nexus. Distinguish between different repository URLs for releases and snapshots.

Make the build fly on our CI server (GitLab-CI). We need the Gradle binary and the Nexus credentials here as well.

That’s not a trivial build, but nothing really special. We are doing this with Maven for many years.

Enthusiasm

First, Gradle impressed me.

Great Flexibility . Highly customizable build.

You can easily create your own task and do whatever you want.

You can take advantage of the fully-fledged programming language Groovy. You can use conditions, loops, subroutines and any Java libraries. For a build script, this is very useful.

Performance

Gradle offers many...