I've personally always found Gradle more intuitive to use and of late they've been shipping a lot of tangible improvements. However, I still see a lot of people who prefer Maven and I'm curious as to what the reasons are that drive that preference.
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (10)
Because all promises that Gradle advertises are not delivered.
1) Gradle is fast: It is not - if you don't count the incremental compilation, which Kotlin has built-in. I have ported one project from Gradle to Maven. And both cold build and hot build were about the same speed, except sometimes, Gradle daemon crashed. Note - Kotlin compiler plugin was set up for incremental compilation, and I used Maven Daemon - see the
mvndproject.2) Gradle is simpler: It is not. There are many aspecs of this:
a) Multi-module builds
When building a really complex app with many optional plugins, transitive deps conflicts, BOMs, and a matrix of supported versions, handling it with Maven is way easier. That's because Gradle was born from a misunderstanding of Maven, starting with immature build model, but later, as it matured, it is getting closer and closer to the original Maven concept. Not sure if it's there yet, but last time I checked, it still did not cope wellwith complex dependency graphs. BTW. that's also the reason why Spring had to introduce an entire plugin to deal with dependencies in Gradle, while Maven has just a BOM.
In one major world-wide company, there were a couple of big Gradle fans, working on a common layer used by all apps of a platform. And even after 3 years of working on that, they still did not figure out versions conflicts, distributed excluding, and regularly broke the build of some applications. Plus, the jar of the layer was accompanied by an invalid pom.xml produced by Gradle's bug (which is proudly advertised as a feature, because Gradle's authors know better how a Maven POM file should look like).
b) Specific features
Whenever you are going 1 centimeter beyond the basic use cases covered by tutorials, you're in troubles. While there's a Maven plugin for pretty much anything (at least for the JVM builds). in gradle, you need to resort to ancient Ant plugins, or use plugins from a random guy on github. Good luck with your security audit.
c) Syntax
Yes, XML. When the syntax is all you care about, go with Gradle. But Gradle's syntax (both Groovy and Kotlin) is a leaky abstraction. It tries so hard to hide from you that you're actually in a programming language, but it fail. And fails badly. Recently, I asked a junior developer to declare a version of a framework at one place and use it for it's libraries. Even with such task, he hit some obscure compilation error which gave no hing on what's going on.
And this is typical for Gradle: The syntax is simple when you see it in an example, or as long as all you do is add dependencies. Once you want to sign jars, create executables, do reports, do sites, generate documentations, stage, release, create docker images, run complex testsuites with many resources being set up - Gradle becomes ridiculously complicated, and everybody just escapes it and tells you "why would you want a build tool to do that"?
Ok then - you may argue that a build tool should be dumb and only capable of downloading jars, compiling some source code and producing a jar. But I got used to the comfort provided by Maven and see no reason to leave it just because it uses XML.
And you can use 10 other tools that can each do it's thing, with yet another syntax, yet another installation procedure, yet another config files, cluttering your build and confusing your developers more and more.
And if you really can't digest XML, then Maven has 2 projects aiming to provide alternative syntaxes: Polygot, and one more I don't remember. They have issues with releasing, but still better than releasing with Gradle.
d) Plugin development
I've tried both. Doing a plugin for Maven is a piece of cake. Just go and try. Even the aggregating plugins are quite easy.
While doing a plugin for Gradle, if it's supposed to be a well-integrated well-behaved plugin which can manipulate the whole build process, is a big mess. You can't really count on anything, because the Gradle script author can achieve their goals in too many different ways. Supporting them all is really difficult.
3) The users following the best practices
Maven has a stable, mature way of describing the projects. There are well-known boundaries of what a module should be, and the POM authors are encouraged to modularize their projects. Not doing that results in so impractical pom.xml that it becomes obvious you need to split. The result is a nicely structured project with nicely separated areas, typically following the modularization of your apps and the platform.
I Gradle, I have way too often seen a sad state of a spaghetti code of Groovy, Ant tasks, Bash, Docker, Bouncy-castle code copy-pasted from somewhere into a .java and provided on a classpath to the Gradle script, and similar. It is because the Gradle community doesn't even think that splitting the project into modules is a good thing. If they produce multiple jars, they do it so within the same project. (As observed by me.)
4) Project customization
Maven plugins are very well documented, and because the plugin development is simple, also if you are (rarely) not sure about anything, or miss a feature, you can go to the plugin project and read, or change, the code.
In Groovy, when I wanted to port what I had in Maven, I spent many days figuring out individual aspects, and often had to resort to workarounds which I found in Gradle's bug tracking, with the explanation "why this is not possible and I actually do not want to do it". Without any alternative but doing it with another tool.
There are more aspects of simplicity, and more reasons why I don't use Gradle, but these are enough not to consider Gradle for any serious project.
If you have a developer / architect, choosing a tech stack, and he/she stops considering Maven just because it uses XML, maybe you should consider twice if it's a person in the right place.
I would personally prefer Gradle over Maven for following reasons:
Hmm. Many years old version sucks. Ok then maybe let's compare Gradle 1.x with Maven 2?
And regarding "it's much easier to write plugins and extract parts of your build in separate files."
That is exactly the reason why I would not choose Gradle - because of the inventions that the developers bring into the build. Instead of describing the project, Gradle falls back to command the tools what to do, without any value added. Maven has managed to build a build culture which leads to actually readable builds - not in terms of concise, but highly standardized and quickly understandable - compared to Gradle spaghetti code.
Personally, I like the idea of gradle, but don't like groovy. For me, groovy is counterreadable. If only there was a way to do the same with plain Java...
It might be not obvious at the first sight, but whole Java ecosystem is mostly built on top of maven dependency management. In other words, maven is the native tool for this purpose. And while POM syntax is clunky and verbose, maven is the tool which introduces important innovations/features (like BOM's or support for recent Java versions), rather than one that catches up. Maven is better supported by IDE (and importing it into Idea does not take ages). From my personal experience I can add, that I never had issues with artefact reproducibility with maven, only with gradle.
After all, gradle is just plugs in into maven ecosystem, not vice versa, so why bother with yet another intermediate layer?
I'm always perplexed when I see the vast amounts of people who use Maven over Gradle. This is especially prominent in the Spring world, I've tried out both and have chosen Gradle 100% of the time, Groovy seems so much easier to work with than XML.
Maven was the only game in town when I got started with Java, and I just plain don't like Groovy.
The Kotlin DSL is stable and usable now, so that's worth a look to avoid Groovy.
It's just more of the same. Different smell, same Gradle.
When I started out everything kept telling me to use Maven so I did, then I worked a bit on Android and I found myself checking out Gradle.
🙊