Maven or Gradle

When do we need them and which one is more efficient when working with java.
Which one do you prefer and use ?

Maven comes with Eclipse, one of the most popular Java IDEs.

This could be as dangerous a topic as "emacs vs vi", "Eclipse vs IntelliJ", "Windows vs Linux vs Mac", etc., so I'd like everybody to not start bashing the tool you don't like.

That said, I've never really worked with Gradle, I prefer Maven. It's what I started with, and with the right plugins it can do what I want. And with the upcoming Maven 4 several issues should get resolved as well (like running the SonarQube plugin combined with only "initialize" not working properly for multi-module projects).

Rob Spoor wrote:This could be as dangerous a topic as "emacs vs vi", "Eclipse vs IntelliJ", "Windows vs Linux vs Mac", etc., so I'd like everybody to not start bashing the tool you don't like.

Fully agree .

My two cents about the topic:

After some trial of Gradle I always went back to Maven despite the fact that I am always struggle with reading the XML syntax.

The thing that keeps me with Maven is the Maven lifecycle concept, and of course the strict standard directory layout. This enables to find myself "at home" even with unknown Maven projects after the step to wade throught the XML syntax.

An ideal build tool - for me - would combine above mentioned lifecycle and directory layout with a more human -readable language e.g. YAML but this choice is not given when comparing Maven vs. Gradle.

Efficiency can be measured in many ways. I have a lot more experience using Maven than Gradle so the greater familiarity with Maven makes me more efficient when using it. When I do use Gradle it's a process of trial and error followed by an admission of defeat and some documentation reading.

On a technical consideration, I might reach for Gradle over Maven if I wanted to manage a project that comprised of modules written in different programming languages. Otherwise, they pretty much serve the same purpose so go with the one you and/or your team are more familiar with.

Since you're choosing your build tool which is an "architecturally significant" decision it would be worth recording it in an Architecture Decision Record so you and your successors know why you chose it.

Carey Brown wrote:Maven comes with Eclipse, one of the most popular Java IDEs.

I'm not sure that's true. Maven support for Eclipse is handled via a plug-in, as as virtually everything in Eclipse, up to and including Java language development support. Eclipse itself is essentially an OSGi framework.

What we call "Eclipse" is available in several different "spins", which are distros with certain plugins pre-installed. Last time I looked, there were two different spins for Java -- one for generic Java and one for Enterprise Java. And a C-language development spin, plus others I forget. There are additional spins from other places than eclipse.org, but we won´t worry about them.

Originally, at least, the Maven plug-in was NOT pre-installed. As to which, if any, current Java spins have it pre-installed, I don´t know. If Gradle support isn´t (yet?) pre-installed, so be it. Gradle is definitely pre-installed in the Android developer kit from IntelliJ.


Regardless, my own personal experience and preference for most Java projects is Maven. Gradle has better support for mixed-language environments (and for example, Android is often Java+Kotlin). But Gradle builds have been much more fragile in my experience. A Maven build tends to be good for the ages.

As far as dependencies go, Gradle pulls from Maven Central just as Maven itself does. And for that matter, Ivy for Ant. That makes like a lot simpler as you don´t have to worry about which build tool matches your dependencies.

Just wanted to give my 2 cents. I've used Maven for a long time. Then I used Gradle in a contractor project and liked it better. Also I had some issues when configuring multi-module projects for a Spring Boot application, most probably my fault of not understanding something.

Both are solid options, and I don't think you'd regret choosing either of them. Maven is the old guard, and Gradle is the new kid on the block who's grown pretty old. Maven almost always have a plugin for what you need to accomplish. With Gradle, if there isn't one you have the option to code it yourself in the build.gradle script, as it is a Groovy/Kotlin DSL. So writing your custom actions is easier in Gradle, imho. I also like the multi-module project support better, but that might be me not knowing Maven that well. Build pipeline looks clearer on Maven, it is easier to put a task in the correct place. Gradle feels more like the Prolog language, you don't tell when to do it, you imply by when it should have been done.

For tooling, I think both are solid. Every major IDE has support for both, as far as I can see. Every major CI/CD tool supports them.

Not going to "bash" Maven... it's a solid workhorse many projects do fine with.
But I'm definitely solidly in the Gradle camp.

The way I view it:
Ant (+Ivy):
Nice and easy to understand since it's just executing commands in order. +1
But you need to deal with that awful XML. -1


Gradle:
Steeper learning curve than Ant -1
...but NO XML! And you can even use Groovy/Java if you really need to. +1


Maven:
Steeper learning curve than Ant -1
...and you need to deal with a ton of awful XML. -1

Final score:
Ant 0
Gradle 0
Maven -2

So Maven's the worst of both worlds on those (cherry picked) very high level criteria. Ant's basically dead now, so I defaulted over to a Gradle preference.

Ant still has its virtues. Tomcat is among the major apps that uses Ant to build. Ant allows you to lay out your project however you want, create complex build rules and construct multiple products in a single build. Its major weakness relative to Maven/Gradle is dependency management, and Ivy addresses that.

Maven and Gradle projects can only produce single products, although by stacking them you can create multi-product results. As I said, Gradle excels in its ability to produce products in a mixed-language project. However, I've had some bad experiences with Gradle breaking when stuff is upgraded, so I remain guarded.

Unlike Gradle, Maven is intended for Java-only projects. It is, however, more stable than Gradle.

As for XML, you don´t even need an IDE to edit XML. Even the vim editor has an XML plugin and Emacs often distributes with the XML mode pre-installed. Yes, XML is ugly and verbose, but it can be automatically validated (although full schema validation isn't an option for a POM or Ant build file).

Then again, though it isn´t as validatable as XML, YAML is my general preferred complex config language. And as a rule, you can swap out an XML file with YAML. In fact, the Spring Framework is a system where either YAML or XML is allowed. It should, in fact be relatively easy to retro-fit even legacy Maven releases to take YAML POMs, should anyone care to do so.

I'm no Ant hater at all, I stuck with it as long as I could. But I started feeling a little Jurassic about it.

Upgrade craziness is definitely a downside for Gradle, I agree. I just use SDKMAN to grab whatever version I need (and use a Gradle wrapper to bundle the correct version with the project for build reliability). Those Gradle people are seriously bored, like a Google developer, seemingly changing things like trivial syntax for no obvious reason.

Whenever I compare Maven build files to Gradle, Gradle is normally far shorter and easier to read. Especially when you have a lot of dependencies. That XML bloat really adds up.

One thing I forgot to mention. The downside to Ant allowing you to organize a project any way you like is that it will be organized any way you like.

One of the things I initially balked at was how Maven wanted you to organize projects in a way it liked. Probably some residue from early-generation IDEs forcing a vendor-specific layout on their projects made me wary.

Since then, however, I've learned to appreciate that given a Maven project, I will know in advance where to find what. And, for that matter, a "mvn clean" and a ZIP will allow me to ship a project to anyone in the world without worrying about how they organize their filesystem. All they have to do is unzip and build.

Gradle, as an extension of Maven concepts also benefits from this approach, of course.

H Qam wrote:When do we need them and which one is more efficient when working with java.
Which one do you prefer and use ?

Caveat: I have used both, though I am not an expert in either.

Similarities:

Both Maven & Gradle are practical, amazing, powerful, and popular tools for managing your Java project.

Both do the same jobs: (a) manage dependencies, and (b) manage compiling and building your app to produce artifacts like JAR files.

Both use the same Maven dependency repositories for obtaining libraries you want to call in your Java project.

Differences:

Gradle lags behind the latest versions of Java. Gradle depends on both Groovy and Kotlin, which lag Java releases. If you want to use early-access or brand-new Java, then stick with Maven. I gave up on Gradle for some projects because of this issue. But for other people, this may be a non-issue.

Gradle can better meet some advanced needs. For example, I have seen comments saying Gradle can more gracefully handle multi-module projects (sub-projects that produce an artifact) whereas Maven can struggle there.

Gradle’s syntax is actually a programming language (previously Groovy, now Kotlin seems to be favored). While this is more powerful and flexible, you can also shoot yourself in the foot more easily. And newcomers may get lost in complicated custom Gradle scripts. In contrast, Maven uses XML for true configuration files. This means Maven files, while less powerful & flexible, are simpler given the built-in restraint of being mere configuration.

My recommendations:

Definitely use one or the other to manage your projects. (Or use an up-and-coming alternative that may appear.) Do not use an IDE’s own proprietary build system as that locks you into that one IDE vendor. Maven & Gradle makes your project portable across IDEs. All major IDEs support both.

Start with Maven. It is simpler. It gets the job done very well for simple apps. Your first POM files will be brief. Later, when you grow into complicated build situations, consider switching.

The XML in Maven is *not* a problem, no big deal. Your IDE manages the spacing, formatting, colorizing, and validation of the XML tags. You will always be cutting-and-pasting blocks of XML from another project, from a snippet on the internet, or from an AI suggestion. I have *never* typed an XML tag in a Maven POM file. I roll my eyes when I read the complaints over XML, the equivalent of choosing one automobile over another because of the window-washer control being a twist-rod rather than push-button.

Know that switching is *not* difficult. We’re talking French & Spanish, not French & Mandarin. Both Maven & Groovy have the same concepts, accomplish the same tasks on your To-Do list of software-building. Both cover the basics with built-in features, while both support less common tasks with plugins. Learning these build concepts, overcoming build challenges, is the tricky part — and that knowledge you take with you when switching between Maven and Groovy.

I'm slightly biased towards Gradle, maybe from a distaste of XML and a preference for the ability for something more flexible. Gradle build files can get messy too, just like those old Maven configs with a bunch of Maven plugins.

The XML is fine for a simpler project, and I admit it's not THAT big of a deal in the grand scheme of things. Compared to the grossness of a big Python project or Rust, it's insignificant.

Gradle does lag behind Java versions. But it's not an issue most of the time since it's a good practice for important production stuff to not be so bleeding edge.

Supposedly I think Gradle is faster to build (especially with repeated builds IIRC), but I don't know that for sure. And that only would really matter for a large build anyway.

Basil .Work wrote:For example, I have seen comments saying Gradle can more gracefully handle multi-module projects (sub-projects that produce an artifact) whereas Maven can struggle there.

The Maven team promises that Maven 4 will improve on that a lot.

Lou Hamers wrote:Supposedly I think Gradle is faster to build (especially with repeated builds IIRC), but I don't know that for sure. And that only would really matter for a large build anyway.

mvnd can supposedly help improve that. I haven't used it myself yet, but it looks to be something like Gradle's daemon which means it doesn't have to reload everything from scratch every single time.

Interesting, I was starting to get the impression that Maven wasn't actively developed and was just in maintenance mode. And people keep saying "Java's dead" or whatever...