Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Java Build Tools – Part 2: A Decision Maker’s Comparison of Maven, Gradle and Ant + Ivy

Above is a slide show previewing [most of] the results for only the truly impatient coders out there ;-)

Chapter I: Introduction

“The evolution from Make, to Ant, and then to Maven has done precious little to advance the state of Java build tools. Developers are still stuck with poorly thought-out tools that force us to violate DRY and write XML tag soup. Your team may be better served using a less popular alternative.”

- Jess Johnson in October 2010, http://grokcode.com/538/

DOWNLOAD THE PDF


Oooh, more on Java Build Tools. Hooray :-/

java build tools part 2 maven grant ant + ivy

Believe it or not, Java developers don’t consider build tools to be the most interesting topic out there. They are generally not considered the most exciting segment of any developer’s overall utility belt.

After all, the majority of the dev world still chooses between just two build tools, Maven and Ant, the latter of the two having been created nearly a generation ago. At best, programmers would prefer their build tool remain invisible and stable; at worst, we hear complaints of downloading enormous libraries, scripts failing for no reason due to some invisible rule running in the background, and general annoyances.

However, build tools should still be able to rock, and it’s in the spirit of “Build Tools [Can] Rock!” that RebelLabs has set out to finalize our journey into the realm of Java’s three most popular build tools–Maven, Gradle and Ant (along with Ivy for managing dependencies). After all, if anyone was going to try to put it a little “sexy” back into Ant, it would be us ;-)

This all started in December 2013, when we published Java Build Tools Part 1. It would help to think of Parts 1 and 2 as a single publication, broken into two sections due to length and time restrictions. In Part 1, we showed developers how to get started with all of the tools mentioned, we reviewed some tips and pointers on creating the build script, interacting with communities and how to use/create plugins for your overall development environment.

In Part 2, we go deeper and get out the proverbial red pen, taking each build tool and ranking them in six categories, then applying those scores to four common user profiles (i.e. use cases) in order to figure out which build tool makes the most sense for you. But now, let’s review where the general Java development industry stands in terms of current and historical build tool usage.


What we’ve been using over time

Here is a timeline going from 1977 to 2013, showing how things have emerged over time. You’ll notice that MAKE and SBT are mentioned, but aren’t appearing in the report due to lack of higher representation in the world. But they are worth looking into as well, just FYI.

java build tools part 2 evolution of build tools

Considering the timeline here, it’s probably better to look at Build Tools in use since 2010, and we’ve seen the following trends over the last few years. Here are the self-reported statistics from three years worth of developer data.

From what we can see, Maven is increasing at a steady rate​, Ant is losing market share and Gradle is increasing at a more explosive pace. It would not be incorrect to suggest that people are migrating from Ant to Gradle, but it’s equally likely that Ant users go first to Maven (which is also XML-based) and then proceed to Gradle.

java build tools part 2 tool popularity

In any case, which tool developers use is not always up to them. However, by ranking these tools against six categories for four different user profiles, we hope to shed some light on matters. In Chapter II, here is what we test and compare:

  • How easy is the initial learning curve?
  • How fast are different builds with each tool?
  • How complex is it to create and maintain the build script?
  • How many plugins exist and how simple is it to customize your own plugins?
  • How good is the community and documentation for each tool?
  • How well does each tool integrate with developer tools? (IDE, App Server, CI server)

From there, we take those scores and apply them across four user profiles–from hobbyist developer and OSS project creator to a developer inside of medium-sized organization and developer #12645 in a global megapower.


DOWNLOAD THE PDF

  • Roberto Cortez

    Hi! Great article as always. Just a quick question about Gradle build speed:

    Quote: “Gradle suffers here from a longer initialization time”

    Were you using the Gradle daemon? Could be interesting to compare times running the build by using/not using the daemon.

  • Mr Platypus

    What was that line from the The Cleaner in Pulp Friction when Jules and Vincent finally cleaned up the mess??

  • Todd Trimmer

    Slides 14 and 15 were redundant with 13.

  • Mike

    Boy, the Gradle documentation must have improved A LOT for it to have received 5 stars here. I used Gradle for a very small Java project early last year and it was very hard for me to bootstrap. The docs all struck me as either too high-level, or way too detailed, and there was little example-based documentation of the common things. I went into it really wanting to love it, but ended up mostly loving how compact my build ended up (after lots of suffering getting it put together), and how Gradle made it easy for new developers to bootstrap.

    That said, I must admit I came to Gradle from Ant, and wasn’t used to Maven-ish idioms.

    If the docs have improved to that degree, it’s a big win, IMO, because even with my frustrations I felt it was potentially a really great tool.

  • maxandersen

    Great slides but the IDE comparison “forgets” that i.e. maven in eclipse and I believe other IDE’s supports configuring specific type of web projects and plugins. With gradle that does not happen (at least not yet)

  • Oliver White

    This one? “What about you, lash laroo? You think you can keep your spurs from jingling and jangling?”

  • Oliver White

    This is actually coming up soon Roberto! After hearing from the Maven and Gradle folks, we redid some of the performance tests and will get the updated stuff out soon–bad news for Maven though, they had originally won this category and now it seems like Gradle is faster here as well…

  • Ries van Twisk

    Looks at this:

    https://github.com/zeroturnaround/maven-jrebel-plugin
    vs
    https://github.com/zeroturnaround/gradle-jrebel-plugin

    I would like to say ‘I rest my case’ but here is what I have to say:

    I don’t consider myself a expert in maven, gradle or java for that matter. But I each time I come across a maven project I tell my IDE to import it and ‘voila’ off I go debugging, adding features or whatever…
    Each time I import a gradle project I spend the next half hour to figure out the dependencies and setup my IDE. I do admit that I don’t use gradle a lot myself so may be I am doing something wrong.

    From a bird’s eye view gradle does like awesome, and maven looks terrible (due to the XML) but once you work with itup close I do much better like the strictness of maven and hate the build files I come across that alway’s look different from one to the next.
    I do understand why sone large project move away from maven to gradle, but they are usually large and have very complex build’s so you gotta script some thing’s in favour of maven plugins.. I understand that!
    But in a lot of cases, I see build’s that shouldn’t be made in gradle the way they are and they should just stick to maven because it follow’s standards better and make’s life in general far easer.

    I personally don’t care much about build speed, I use jrebel for my work which really speed up java developments and if I really need to be that 10% faster during a full build, I will buy faster hardware..

  • Brandon Enochs

    It seems slightly disingenuous to us the daemon flag when comparing Maven runtimes to Gradle without using the -T option in Maven. I’ve found that Gradle startup time is significantly slower than Maven’s without that flag. Any idea why it’s not on by default?