Why Build Your Java Projects with Gradle Rather than Ant or Maven?

We've already come a long way in clarity, reproducability, automation, IDE independence, etc, when the industry moved from Ant to Maven in the first part of the 00'ties. Gradle seems a step back from this. I'm not sure what problem it really addresses where the advantage over Maven justifies having to learn a new language (Groovy) and a new build tool.

The author posts a Maven project (POM.xml) and the equivalent Gradle build config and then says "cuts down on build script size and far more readable". Let's take these arguments one by one:

(1) build script size. Do you mean the number of bytes in the build script? Sure, XML is verbose in this sense, it sucks for things that need to travel a wire, but for expressing config data I believe it is okay. It is not a big thing that it is verbose. The advantage is that it gives the IDE the opportunity to validate your POM. Wouldn't know how to do that with Gradle as the config is really a Groovy script which is a programming language, which means anything goes, really.

(2) Readability. Well my IDE provides syntax highlighting of XML so it is very readable, for me at least. Just about the same as the equivalent Groovy script.

As a Java developer I have about a hundred "new things" every month that I should learn to continuously develop myself. All of us have limited bandwidth. I regret the time I spent with Gradle when indeed Maven was already safely under my belt. The dividend just wasn't there.

I've used Gradle on a few projects and it just doesn't feel like a step forward. I admit that if you come from nothing (e.g. Ant) then it may be easier to learn than Maven and will give you immediate benefits. But if you want to make a living from being a Java developer then you'll be forced to learn use and learn Maven anyway (because it is so widely used) and then Gradle just feels like a solution looking for a problem.

If you are in Open Source then you also need to consider if the build system you use is a turn-off for contributors. I don't contribute to Ant-based projects. It just takes too long time for me to configure everything. I contribute actively to maybe 5-6 projects and infrequently to dozens of others. Of these only a single of these was/is Gradle-based and whenever I wanted to contribute I had to go back and dig in my brain for my Gradle skills. With the 95% other projects that hurdle wasn't there for me. The fact that everyone uses the same isn't a bad thing and lowers the barrier-to-entry. If you wanna break ranks with your project, then you'll need a damned good reason, IMHO.

I would like to hear of a well-established open source project which already used Maven and then switched to Gradle, and learn why they did it. That would be interesting. But I've yet to come across one.

The critique of Maven "how do you create two different JAR files from one source tree" is exactly the kind of thing you shouldn't want to do. 12 factor apps build one artifact per codebase ( http://12factor.net/codebase ), something Maven has been doing forever. Making your build tool more flexible so you can introduce poor design principles is not a step forward.

One of the issues I did see when using Gradle is that developer's are trying to make there own build. You will see thing's "Create file this and that and fill in our details".

You would see that people start to use different build directory styles and other 'oddities'. When importing a Gradle project into you favourite IDE, then nothing works because Gradle is hard to import. Then the 'How to build' seems to be different between projects.
Except for the IDE importing (I don't like vim, sorry, this is not a flamewar aswell) the above can be solved if people know what they are doing, unfortunately in the real world a lot of people don't know what they are doing and don't understand the benefit of standards.

I know maven has it's flaws, but it does work well in reasonably small to medium projects just fine. If I import a maven style project in my IDE, everything is setup ready to build and test. My IDE know's the dependencies, know's how to build a project and how to deploy.
With gradle style project's this was never the case, I am curious to know the current state of Gradle in my favourite Idea (Idea) though and see if this has been improved.

Gradle properly has a future, but I am pretty sure that maven is here to stay..

I haven't read the entire article, but I don't need to be convinced. Gradle is the build tool of the future.

However, it has some competition that isn't really described here. In the last few (internet) years, web applications driven by Javascript have become significant enterprises with complex functionality. The build steps for these applications have become complex, requiring tools that can manage this complexity. There has apparently been a perception that the available build tools that were typically used for Java applications, are not appropriate for building these applications.

This has resulted in the use of Grunt, and now Gulp, along with auxiliary tools, mostly based on a NodeJS infrastructure. These build tools are written and configured with Javascript, which is very natural for web developers to work with. This suite of tools is growing and evolving quickly, and completely ignoring Gradle.

Although heterogeneity is something we should learn to live with, it's never optimal to deliberately go in that direction. It would be best if Gradle could be used for building all kinds of applications, and I think it might get there. However, in articles like this, I don't see much of an attempt to sell to the web application domain, which adds to the divisiveness of this domain.

Gradle could make significant progress by making a concerted effort to address this shortcoming, even if it is only a perception.