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

Sonatype questions Maven scores in follow-up to Java Build Tools report

Before we start, we want to remind you that one of the reasons developers like reading RebelLabs is because we’re developers just like them–not necessarily experts, or special gurus of any kind. We’re interested in learning and writing about topics from the perspective of an everyday curious developer.

So if we omit some special shortcuts or script in the report, it’s because we couldn’t find it or didn’t know about it–just like the average developer who’s just looking to get set up without researching the internetz for days in advance. Prior to the previous report’s launch, we did some small outreach to Sonatype (never heard back), the Apache Software foundation (never heard back and didn’t expect to) and to Gradleware (DID hear back); however, after publishing Part 1 of the report series, we STILL didn’t hear anything from the Maven side of things, even just to say “Hey, we’re totally busy but we acknowledge that you spent hours writing a report that focuses on Maven”.

Screenshot 2014-03-14 12.41.36

Our take is that Maven was a groundbreaking tool when it was introduced–and still is, based on how the vast majority of Java developers out there use it. Maven changed the way that build tools and dependency management worked when it was first introduced (like we mention in this group of articles which also received no response from Sonatype).

Special note: I would like to thank Sonatype’s Manfred Moser, who is a Maven trainer, plugin committer and community advocate, for poring over this report and giving his honest, passionate feedback. Thank you Manfred!

Manfred Moser (MM): Here is a bunch of general and detailed feedback. Overall there is a bit of a slant towards Gradle that seems not based on facts.

RebelLabs (RL): Hehe, that’s the tricky part with the term “facts” here–we’ve always thought that developers didn’t like being told “the facts” about their judgement and evaluation of a tool.

MM: On page 4 you have this paragraph:

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.

But your data does not suggest suggest a migration to Maven and then to Gradle. You can not truly make this conclusion. I am sure lots of people are just migrating to Maven from Ant are NOT considering to move to Gradle at all. In fact I have a few clients that consciously choose Maven over Gradle (very large corporations..)

RL: Notice that we write “It would not be incorrect to suggest”…and we purposefully use language like this to express our opinions, not anything we’d call a fact. Our data doesn’t prove anything, we’re just thinking about it from a real developer’s perspective. The sharp decrease in Ant and increase for Gradle would imply that people are skipping from the oldest technology to the newest out there, but it’s also likely that a migration path would go from Ant > Maven, which presents less of a barrier, and then maybe trying Gradle later. Keep in mind, this question asked about non-exclusive tool usage by developers: the market is coming from somewhere obviously, and Gradle’s growth and success is a good indicator of that.

Build scripts and writing your own Maven/Ant plugins

MM: On page 6, you incorrectly state that you need to use Ant to customize a build script. This is not true at all. In many cases you can just configure an existing plugin that does what you want and if you truly want to just script you can easily use Ant (antrun plugin), Groovy (gmaven) or any other scripting tools (exec plugin) or VERY easily write your own plugin. In terms of getting started you are also forgetting that Maven has s template system for projects (archetype) with hundreds of pre-defined templates available.

RL: We state clearly that to customize scripts, you have to use plugins which certainly adds to a developer’s overhead. And if there is no suitable plugin available, then you can use Antrun with an Ant script or write your own plugin. We also stated that it is easy to write a plugin for Maven–and in the feature category on plugins, Maven was the winner. The templates however were not mentioned at all, but that wouldn’t increase Maven’s mark much higher (it was already high).

MM: When you then write about Gradle you say its easy because you already understand everything from using Maven… well thats not fair. In my experience people are actually turned off by the power of Groovy that Gradle offers and get overwhelmed with the feeling of having to learn Gradle and Groovy.

With this in mind I find it weird that Gradle gets a higher score than Maven. Also with the Ant setup you forget that you have to actually write your build script. So you have to basically create your own build lifecycle.. something that comes out of the box for free in Gradle and Maven.

RL: Well, statistically most users have gotten used to the “Maven Way” and find the lower amount of conventions needed to set up Gradle to be quite a bit simpler. Plus, we’ve heard several times that devs are willing to accept Groovy syntax in the case of Gradle, but no matter. We mention at least once that one needs to write a huge build script with Ant. From the perspective of an average developer, getting started with Gradle without any pre-existing knowledge was simply more enjoyable than for any other build tool. If any bias has snuck in, then we believe it’s a reasonable thing. We enjoyed working with Gradle from the start, and that’s the point.

Performance test correction, links to Super POM and Eclipse

MM: For the performance test you are making a crucial Maven mistake. You are calling the build twice! Your command line from the table is:

mvn -Dmaven. test.skip=true clean compile package

This causes Maven to run clean, then everything up to and including compile and then everything again up to and including package (which includes all prior phases like compile). You should change this to:

mvn -Dmaven. test.skip=true clean package

You are also not mentioning if you are setting any sort of parallel build or compile options which can make huge differences.

RL: We have corrected this oversight according to your suggestion, and the new figures are in the report now.

MM: Last but not least in terms of performance you have to keep in mind and should mention that incremental build happen automatically within the IDE if you use Eclipse and M2e …

RL: This comment is more for the IDE section, where Maven scores top ranks…however, if you aren’t using Eclipse then you’re out of luck.

MM: Your link to the super pom is wrong. E.g. a correct link to the 3.1.1 super pom is

RL: Updated, thanks. Even now, this is not very easy to find. Running a search produces this: … and this: — perhaps some redirection on the site would help users find the latest version?

On using Maven shell and Gradle daemon

MM: I am not sure I agree with using [Gradle’s] daemon but whatever..the daemon is not the default behaviour of Gradle. In the same manner you could use e.g. the Eclipse integration of Maven that never needs to rebuild or the Maven shell that works like the daemon.

RL: Again, we wanted to go through things from the perspective of the “average developer” and use all the obvious tools in the arsenal. The examples you give above ignore IntelliJ IDEA and NetBeans users btw, and the Maven shell you describe doesn’t appear to be in the standard distribution of Maven, whereas the daemon is standard with Gradle.

We couldn’t even find how to download or start the Maven shell on Google. After searching for some time we uncovered 3 posts on Sonatype’s blog with the “maven shell” tag all from 2010–this post has a broken download link that redirects users to the Sonatype home page. Given all these hurdles, we believe it’s reasonable to have omitted the Maven shell that we struggled to find out about even after you mentioned it to us.

The “Maven Way”

MM: There is nothing non-obvious or so happening at all [in Maven]. It is simple inheritance just like in Java and in M2e or in the command line you can simply view the results of the inheritance by inspecting the effective pom. The paragraph about Maven seems very partial. Gradle internally has a very similar approach in that it defines a lifecycle. The only difference is that it is defined in Groovy and not XML and Java. On the other hand in Gradle plugins often have their own lifecycle and that leads to incompatibilities. E.g. you can’t use the Java and the Android plugins together in Gradle…and in Maven…just like in Gradle you can also override everything with.

When reading on into the conclusion section the same slant towards Gradle based on misconception about Maven comes into play. E.g. do a lot of open source development and using Maven makes it very easy for my committers to get up and running with my projects on the command line and the IDE and it makes it very easy to publish my code to a repository like Central as well. With Ant or Gradle this is quite a bit more painful.

RL: We commented in this way based on the hidden Maven default settings that many devs would not understand out of the box. When asking our developers about this, they all agreed that this was the case, and is represented by the so-called “Maven Way”. Again, this is how the average developer would look at it, not a Maven expert.

We understand that you can change what each lifecycle phase is bound to (through packaging) in Maven, or add to them (through plugin definition); but if you want to change or skip phases, it gets more tricky, e.g. having you create your own packaging that you then have to figure out how to distribute to everyone working on your codebase; as opposed to a few lines in the build script.

As for your example with combining the Java and Android plugin in Gradle–while true, it would make sense that the Android plugin extended the Java plugin, that doesn’t seem to be the case, but the two are also vastly different on some key areas. Similarly in Maven, you wouldn’t both use jar and apk in the same pom file, which is how we think your example is comparing it all.

On bias towards the winner Gradle

MM: In general upon reading the report initially it seemed very biased towards Gradle. E.g. why is it okay and good to have to learn a new programming language (Groovy) and use it inline in the build script and on the other hand writing a simple plugin in the programming language you already use (Java) is not considered good. Even if it is trivial. And you can still write inline Groovy in the build script if you think that is a good idea (or call an external Groovy script or any other script for that matter). It doesn’t really matter to Sonatype at this stage but personally as a Maven trainer and plugin maintainer and consultant I find it a bit bewildering to read reports like that.

RL: In the real world, according to our team many users work with both Maven and Ant together in a generally hackish way. After reviewing the situation, using Gradle never produces a situation where you need to combine 2 different build tools, and you can have a simple script just defining dependencies. At the same time, you can implement your own build script logic quickly in place, without messing around with XML or dealing with combining two build tools together, regardless of all the plugins Maven suggests.

Your last point here seems to be that only a Maven trainer, plugin maintainer and consultant would know these tricks out of the box, whereas it’s pretty clear on Gradle’s website how to do everything so that a beginner can get started quickly.