Review of Gradle in Action by Benjamin Mischke

In my professional experience building the libraries for developing RPC/REST services at Amazon, one of the companion teams I worked closely with was Builder Tools. Cary Hall, at the time "the face" of Builder Tools, was one of the most brilliant minds I've ever met. Conversations with him over the Brazil build system and Apollo deployment system revealed the surprising complexity being "seemingly simple things" like compiling code and deploying built artifacts to different environments.

Like most programmers, build and deployment was always more of a "something that needed to be done but got in my way." In the early stages of my education and career I didn't really bother to learn much about them. Copy-pasting Makefiles/Maven POMs without having a damn clue what the fuck was going on, aside from knowing I needed to change one or two things to make it work for me, was pretty much the way of it. I was learning to make web applications with the Grails web application framework, built in Groovy and using Gradle. I liked Gradle. It seemed "less noisy" than tools like Make and Ant and Maven.

My dissertation exploring the link between Cognitive Load Theory and Software Engineering led to results that suggested such preference for "less noisy" tools has a measurable and concrete impact in our comprehension, maintenance, and evolution of code. Nevertheless, a lot of Gradle seemed like magic that I didn't bother to dive deeper into. Random closures--some with parameters, some not-- weird ordering issues, and other such foibles were encountered and mitigated without deep understanding.

With the exploding complexity of the software world in the 2020s, and my growing feeling that freedom and features are being taken away or occluded by pointless abstractions, it's become more important to me to understand what my tools are doing at a fundamental level. Just what does Gradle do under the covers? What is its architecture, how does it work?

I could just try to read the source of an open-source project, but in many ways that's like landing in a country where you partially speak the language and trying to make your way of it. It's easy to get things wrong or misunderstand. I feel like guided education is important. There's been an explosion of "educational content" created to the point that it's a wild jungle of knowledge. The probability of surviving and thriving in the jungle increase if we have some kind of mental map of the territory and an effective path through it. Most FOSS projects don't invest in all the goodness of providing Krutchen's 4+1 model view, or having UML diagrams to explain complicated systems pictorially, so I prefer having a good book on the subject written by an expert in it. So I picked up Gradle In Action by Benjamin Mischke.

I read a book about Gradle written in 2014 targeting Gradle 1.3-1.4. It is now 2024 and Gradle is at version 8.x with 9.x on the horizon. Obviously, many things are now dated. But an interesting thing about most software architectures is that the core fundamental concepts are rarely entirely thrown out or changed.

Thanks to the book, I learned some funny quirks like Gradle’s task abbreviation. I’ve been using Gradle for years and never knew. The core concepts of Gradle’s initialization/configuration/execution phases help me understand the bodies of some of the code I’ve seen in build scripts a lot better. Though I disagree with Ben’s assertion in Listing 4.5 that “you now have a clear separation between the configuration and action code.” When part of the closure contains code that is evaluated in one phase and another part is evaluated later, and there is an implicit ordering issue, it strikes me that the architecture should do a better job separating those concerns.

I do have some stylistic issues with the book. Ben spends a lot of time in the first couple of chapters trying to sell Gradle, a lot of the language strikes me as needlessly superlative and definitely wouldn’t pass a No Fluff, Just Stuff evaluation. I’m also not a fan of presenting tasks/code examples and then telling the audience “you did this” it feels a bit manipulative.

But the strengths of the book far outweigh the quibbles. The examples lead in directions that are actually useful and professional. It surprises me that to this day Gradle doesn’t have auto-generation for integration and functional tests as part of its “archetype”(in Maven words) or code generation. Learning how to implement them is a nice way of applying the theoretical information.

Even more impressively, he shows how to implement full CI/CD with Gradle. Having read Release It! and Continuous Integration, I’ve been sold on the CI/CD concept for over a decade. I was a bit spoiled at Amazon by having other teams develop automation to generate a full pipeline for you as soon as you create a library/service, so I hadn’t really dived into the details but had a feeling it was always essentially a bunch of chained shell scripts. Actually implementing it all tied together in the build system gave me a lot of ideas to fully automate/professionalize my personal/company’s development. For that alone, I think it’s worth the couple days of reading.