Serious question: Is “Directed Acyclical Graph” really an unknown term for people? The author harped on it pretty hard, but what it is…is pretty apparent, no? I mean, I’ve encountered the term often, but I don’t think I had any need to look it up…

Gradle is absolute rubbish, definitely the worst experience I’ve had with a build system. But Maven is also rubbish.

IMO a CLI should be the primary way of interacting with the build system (see e.g. Go, Rust, JS with NPM or Yarn, Python with Poetry) and manually editing the build file should be reserved for edge cases and extensions.

>Please give me a stable (!) interface to write plugins for “extravagant” features. If other devs are building open-source plugins, I am willing to use them instead of writing them independently.

this definitely does not describe maven. Maven’s interface is terrible, can’t accomplish a lot of stuff (due to the fact that it doesn’t use a DAG…), and people don’t write plugins for Maven. For example, nothing like the reckon plugin exists at all for Maven, and writing one would be an absolute nightmare.

>After the initial effort to write the build file, I should rarely touch it (unless I am incrementing version numbers).

this either means you built the perfect CI/CD process to start and wasted a lot of time on it, or you never improve your processes at all. I completely disagree with this.

>We were momentarily happy not having to write and read (pom.)XML files ever again, and we jumped the boat too early. Our problem was never Maven, but XML…

If that were the case then people would just use Polyglot for Maven and write their build files in Ruby, or Kotlin, or Java, or Yaml, or whatever. But that’s clearly not the problem with Maven.

>Quickly, without opening your CS reference book, tell me what’s a Directed Acyclic Graph

if you don’t know what a DAG is then you’re really gonna struggle with understanding the VCS tools you use every single day…

> This will happen because you never had the patience (by then!) to read the documentation in its entirety. And bare in mind, Gradle’s documentation is not something you can skim on the weekend or from your mobile phone while sitting on the bus. On the contrary, it’s a “hard” read, full of specific technical jargon you need to familiarize yourself with.

I have definitely never read even a tenth of the gradle docs. Yes, Gradle is hard to understand, but just like you don’t have to understand a DAG to use git you don’t have to understand most of it to use Gradle

>Gradle is not the tool you hack your way into by copying paste stuff from StackOverflow. If you haven’t done so already, allocate time to read the documentation.

this is just good advice for all programming (yes, gradle is programming, unlike maven)

>This is not the case with gradle. Incrementing to a new major version is always painful (for non-trivial builds):

ok, which is it? Do you want

> - Let me list a few dependencies by using a purely descriptive approach; > - Please give me a stable (!) interface to write plugins for “extravagant” features. If other devs are building open-source plugins, I am willing to use them instead of writing them independently. > - After the initial effort to write the build file, I should rarely touch it (unless I am incrementing version numbers).

or do you want to build complex builds very easily and be able to modify them in a non-painful manner later?

You can’t get both.

The maven projects I’ve seen and used hardly ever update the maven version. and when we do, it breaks things terribly, except it’s because maven packages its own Java version that conflicts with your build, so not only does Maven not list it as a breaking change, you only find out after you’ve completed the update and then something in prod is broken… Ask me how I know this.

>Please make no mistake; when you choose to use Gradle, you will program your build file, not configure it.

yes… this is why people like gradle more than maven. you actually have control.

>The build.gradle is a running program in disguise

… it’s not in disguise… it literally says in the docs and when you are generating a new project, that you are using either Groovy or Kotlin.

>Without the ability to properly debug the build process and the non-standard hacks people are willing to put in the build file, things can become less portable and extremely environment-dependent or simply not idempotent

Gradle is both more testable and more debuggable than Maven…

>Do you remember when people were creating .sh scripts to build things? There’s a reason we’ve stopped doing so.

yes… because it wasn’t testable… unlike gradle.

>Even if it’s easy to do so, the Gradle build shouldn’t replace a proper CI/CD pipeline,

finally, something I agree with. Yes you shouldn’t replace CI/CD with gradle, I don’t know who is doing this though…

>It ran tests and integrated directly with Sonarqube, created custom reports based on the static code analysis results, performed infrastructure changes, etc. Why!? Because it was possible.

… wat… gradle shouldn’t run tests? it shouldn’t call sonarqube? how else are you going to run tests or call sonarqube? The only one I agree with here is infrastructure changes, but even then, that’s exactly how CDK works. You call CDK to build and deploy your application. You usually do this through npx cdk, but if you wanted to it would massively simplify it to have a single command to handle deploys.

>The reality, this fragmented the community and brought even more confusion to the uninitiated.

yes! yes it did! The switchover was not smooth. But now, every (or at least all the ones I’ve seen) doc has kotlin examples listed before groovy examples. Most people on the forums and the slack only use kotlin. If you are using Groovy you most likely will struggle much much more than with Kotlin.

>Compared to the Groovy DSL, the Kotlin DSL seems to be more strict and more opinionated.

wasn’t the author just saying that you should avoid adding arbitrary logic? Why would being opinionated be a bad thing here?

>So if you are a Java developer planning to use Gradle with the Kotlin DSL, you have to be familiar with Groovy (to be able to read the old materials),

umm. no. no you don’t. The docs have had Kotlin for a long long time now.

>but you also need to learn enough Kotlin to be able to write your build file.

kotlin is wayyyy easier to learn than groovy.

>Why is it necessary to learn a new programming language to master a build tool!?

so is the recommendation that Maven now be written in Java? Or Gradle be written in Java? I don’t get the recommendation here. My team uses Kotlin for everything. We still are mostly using Maven. Using Kotlin everywhere is a huge benefit. We’re trying to switch over to Gradle completely and Gradle having Kotlin as a DSL is fantastic. Needing to deal with XML files sucks, but it’s not nearly as bad as how slow and difficult to configure Maven is. If you’re using Python you need to learn up to 15 different tools and styles in order to correctly build every project out there. Gradle is a multi-language build tool. It’s not just for Java. It can be used for literally any language out there. I’ve seen it used for building C projects even. You could use it to build a monorepo of every language out there. You should be comparing it to Bazel and Buck rather than Maven.

That is not to say that Gradle is the best build system out there. It has a lot of problems with it. It’s definitely not my favorite build system. Bundler, Mix, and Cargo are all much better as a build and dependency management system than Gradle. But Maven is a long, long way down the list.