Why Declarative Gradle is a cool thing I am afraid of: Maven strikes back

Let me provide a quick recall of the history of (Java) build tools.

At the beginning, there was Ant. The fact of its existence is more information than a sensible person would typically need.

Then arrived Maven, the cool kid on the block around 2005. Maven was a very specific solution to a very specific problem: it was a tool used by Apache to build its projects, mostly Java libraries, back at those days. Notably, the widely adopted src/main/java and src/test/java structure finds its roots in Apache’s practices from that era. This narrative somewhat parallels the (mostly fictitious) story linking horse’s ass to space shuttles. Following that, there was a Maven Golden Age lasting until the 2010s, largely attributed to the absence of substantial competition and the relatively simple nature of Java projects.

Yet, the landscape changed. In no particular order:

Maven struggled to keep pace. Its origins as a build tool for simple Java libraries within Apache left it unprepared for the evolving landscape.

Consider build caching. Maven lacks a proper mechanism for it, except a local repository, but that’s not the same. Multi-platform dependencies are another challenge. The GAV notation (group, artifact, version), Maven’s Holy Grail, proves inadequate. And it still relies on a — completely fabricated and opinionated — build lifecycle, organized into dozen-or-something phases. Why not a Directed Acyclic Graph (DAG)?

Enter Gradle, our savior. Despite being ridiculosly complex — sometimes — it was built on a simple idea — a Directed Acyclic Graph (DAG) — enabling it to evolve and adapt to new challenges. That’s why…​

Consider Android projects. They are arguably significantly more challenging than typical Java projects. Their builds involve tasks like processing resources and assets, supporting multiple target SDKs, managing various build flavors, and occasionally dealing with native code and dependencies targeting different CPU architectures. Yet Gradle became the default build tool for Android projects shortly after Android projects even get a build tool! If my memory serves me right, they jumped straight from Ant to Gradle, bypassing Maven, thanks to Google’s influence – a move that I find quite illustrative.

Now, let’s explore other prominent projects in the Java landscape. Kotlin, Spring, Hibernate, RxJava — you name it, they all rely on Gradle. With two possible exceptions. Oracle isn’t particularly fond of Gradle, so don’t be surprised if you discover that GraalVM is built with Maven (it actually is, but the build process is more complex than just Maven vs. Gradle). And, of course, Apache remains loyal to Maven in projects like Hadoop and Spark. After all, it’s their child! Kafka is build with Gradle, though

However, virtually every other major Java project uses Gradle — check your own dependencies!

In essence, Gradle is a superset of Maven. In strict mathematical terms, ponder it for a moment. Everything achievable with Maven can be replicated with Gradle, but the reverse is not true.

Gradle’s DAG is so simple and powerful that you could probably replicate any other build tool with it. The only limitation I could think of: due to the separation of configuration and execution phases, creating and injecting tasks into the DAG on the fly might not be possible. Or is it? Don’t try that at home!

If you have any counterarguments at this juncture, please share them in the comments. I’m genuinely interested in understanding any aspects I might be overlooking 👇

Alright, let’s establish a boundary here.

Gradle is one of the most advanced build tools ever, and unquestionably, it is the most advanced build tool in the Java world.

It’s based on a very simple yet scalable and extensible concept.

However, this scalability and extensibility come at the cost of complexity, and not everyone enjoys its power at this price tag.

So, a while back, a new trend emerged: declarative Gradle. I claim that this concept isn’t entirely novel, and the article I referred to at the beginning of this post essentially encapsulates what has already been circulating, rather than initiating the trend.

The Android Gradle plugin serves as a noteworthy example of declarative Gradle that has been in existence for a considerable time.

Is it really declarative or imperative?

Upon closer examination, you’ll notice that it is imperative! Statements like these

…are extremely imperative!

Or perhaps not? After all, it’s just DSL, isn’t it? And quite eloquent one, I must say. Assignments and maybe a bit of object creation and configuration are inevitable, especially when dealing with software models like this.

What’s more important, is that we don’t see any conditions and loops here. They are the true evil of imperative programming, and here, there are none!

Another example of declarative Gradle are so-called convention plugins. While the documentation about custom plugins may not explicitly state and emphasize this term (which is a problem itself!), it is used in the samples. There is also this cool guy on YouTube, advocating for these best practices as well, take a look!

The idea behind convention plugins is really interesting, and it is very simililar to the AGP example above (in fact, AGP is a convention plugin!): to conceal all the complexity behind a simple DSL. Consider, for instance, another article of mine: No-bullshit guide on publishing your Gradle projects to Maven Central. Now, instead of cluttering your build script with the cumbersome publishing block, you could create a convention plugin, resulting in a build script that looks something like this:

That’s it! You wouldn’t even have to configure the GAV, as the values could be inferred from the project itself. Moreover, this hypothetical plugin could be shared across your company, ensuring uniform publishing configurations for all company’s projects.

Thats really imperative, and this is already available in Gradle!

As demonstrated in the previous section, Gradle is already declarative if you wish it to be! All the tools are at your disposal to conceal complexity behind a straightforward and declarative DSL. Granted, it requires an investment of time: reading the docs, tuning into YouTube, and the like. In larger companies, a dedicated build engineer might be a prudent choice.

However, the article I linked at the beginning actually introduces a new term: Declarative Gradle, 'D' capitalized.

If I understand correctly, "Declarative Gradle" is essentially the same concept as described above but perhaps more trademarked. In fact, "Declarative Gradle" seems to be a more manager-friendly term than "convention plugin", and that’s perfectly fine.

My concern lies in this:

This is disheartening for me because it feels like a step back.

This is Maven, to be precise.

Maven is already a tool with a very restricted DSL (XML; funnily enough, XML could be Turing-complete), where the entire complexity is hidden behind plugins crafted on top of an ambiguous and controversial API. Tinkering with the Maven API is genuinely challenging, while you could kick-start your Gradle plugin right in your build script.

Flexibility is the ultimate power of Gradle, and I am afraid of losing it. I’m afraid of Gradle loosing its charm. This is the reason why it is a better build tool than Maven (and this is the first time I’m actually saying that). It’s about freedom, a quality that doesn’t exist in Maven.

Don’t get me wrong: it’s not advisable to incorporate complex, imperative build logic directly into a build script. There are effective ways to circumvent that, as outlined above and in the docs. In my nearly 10 years of using Gradle, I’ve never used a loop in a build script. I’ve used conditions a few times, probably less than 10 times overall, so less than once per year. However, I now know how to eliminate them completely. The last time I utilized allprojects or subprojects was likely 3-5 years ago, and I know how to avoid them as well.

All these things are avoidable by acquainting yourself with the latest Gradle features. Dive into the release notes! Don’t shy away from using the latest Gradle version in your project either (because if you crave for Declarative Gradle™, an upgrade is inevitable). Embrace the best practices available. If you need a refresher on Gradle, watch that guy on YouTube, he’s brilliant!

I am apprehensive that at the end of this "declarativization", we might end up with a less powerful, restricted version of Gradle. I fear that the Maven mindset — the concept of having a limited but safe tool — might prevail.