What I find fascinating about Gradle is that its utterly impossible to say it lacks documentation - go to https://docs.gradle.org/current/userguide/userguide.html and see the amazing beautiful docs.

But actually learning from those docs is amazingly hard. It's like "documentation theater". If you start as a naive user coming in, it keeps teasing you that its going to teach you something but you just get abstract concept after abstract concept and you STILL don't know the mechanics of how a build works. You have to kind of reverse engineer the info that Bruce describes out of the documentation. Even when you manage to hit actual code examples with detailed explanations - they are described in a way that fails to give you the generalisable understanding of the internals that you need to actually create new things that you haven't seen before.

As a developer it generates a distinctly hostile feeling of helplessness and powerlessness.

I found these to be huge stumbling blocks:

- Scoping is mysterious: things that you expect to be in scope AREN'T, and lots of things that you can't see ARE in scope. This makes it impossible for a beginner to look up the source code (or even, often, the documentation) that corresponds to a given thing in a Gradle file: you might realize that "ext" exists, but there's no way to tell what scope it comes from. That defeats most of the usual approaches that programmers have learned for exploring a new system. To use the UX lingo, Gradle is undiscoverable.

- Similarly, your Gradle script is interacting with things you can't see. When you write "sourceSets { ... }" you're actually calling a method on an object. What object? You can't see it, or even a reference to it, in your Gradle file.

- I came to Gradle with the definition in my head that a build tool is a thing that tracks dependencies so that it only has to rebuild things whose inputs have changed. Gradle doesn't do that at all. Many hours of searching for how Gradle detects changes were fruitless, because it doesn't even try, really. Gradle basically always runs everything, which is why it's so goddamn slow. This is because the entire dependency graph is constructed dynamically on every run, and that prevents the system from effectively retaining from run to run which steps have already been done.

> There are Many Ways to do the Same Thing

This is the crux of the problem, and is a problem with many libraries, configuration systems, languages, etc.

The author of said tool wants it to be as widely used as possible, so he optimizes for the 100%, going so far up the flexibility curve that it becomes incredibly difficult to do 80% of the things you want.

What these authors should be doing is optimizing for the 80%, which means an opinionated top layer that offers a single way to do everything that 80% of your users would want to do. Then if you're smart, you'll have a layered architecture (which the 80% layer rests upon) that allows the other 20% to learn about how the sausage is made in order to do their complex tasks.

With this, you have a common tool that is at least 80% easily understandable with minimal time investment.

Failure to do this gives you unfriendly systems like CMake, Gradle, OpenSSL, Postfix, and Java's time libraries.

U/X applies to code as well.

A bit of a side note here regarding the author.

Bruce Eckel's book "Thinking in C++ Vols 1 and 2"[1][2] was possibly my favorite book ever read. Bruce is (in my personal opinion as an observer of people with zero professional training in psychology) a depth-first learner and naturally seeks to understand how things work by looking at the layers. Building up from there allows true understanding and even mastery of the material.

This is exactly how I am as well, and the result is often that it can take a while for me to pick things up and really understand them (since I have to cover so much more material than a typical person) but my level of mastery afterward is typically very high.

My experience now from well over a decade in the industry is that most people are not this way, and also that many people who are this way don't necessarily realize it. If you feel like understanding history, layers, etc helps you understand things much better, do yourself a favor and follow Bruce Eckel's blog and read his books. Thinking in C++ 2nd edition is 20 years old now. A third edition would be wonderful. Or maybe even better, "Thinking in Rust" :-D

[1] Volume 1 available for free on Archive.org: https://archive.org/details/TICPP2ndEdVolOne

[2] Volume 2 available for free on Archive.org: https://archive.org/details/TICPP2ndEdVolTwo

> This is the problem I had with Gradle:

> To do anything you have to know everything

This sums it up pretty well. Coming from a background of using Maven purely for dependency management and basic compilation, existing Gradle projects are incredibly unapproachable and slow. And don’t get me started on the background daemons to speed things up either.

  val x: Int // this is an immutable value
  val y: Int // this is an immutable Function0<Int> that is executed each time and but pretends to be a val
     get() = System.currentTimeMillis()

The article seems to boil to down to: you need to understand Groovy to effectively use Gradle.

It's impossible to disagree with this, but this is a realization you should have after interacting with it after 10 minutes.

I may be biased because I'd been using Groovy (Grails apps) for years before I used Gradle so the syntax was not a problem at all for me. For me, the problem with Gradle is the very poor documentation. If I want to do something more complex, I either find the answer in Stackoverflow/the Gradle message board, or I will have to look at the source code of the plugins. Creating a task for scratch is fairly simple, it's interacting with the plugins that's difficult, and while I agree with the author that excessive abstraction through DSLs doesn't help, if these DSLs didn't leak and were properly documented it wouldn't be a problem.

Another problem is that it's clear what the right conventions are. Say you want some classes to some exec task. Where should these classes live? Do you use a configuration? Create a sourceSet? Add a directory to an existing sourceSet? You just edit the classpath property in the task to point to a directory? I miss some of the rigidity of Maven, though not its XML syntax. The ability to write actual functions in Groovy (e.g. a closure implementing a file filter) is very much welcome.

The problem with Gradle is that people try to use it, and so try to understand it, and then treat the sunk cost to understand it as a reason to keep using it. Bruce correctly sees being locked into Gradle as a way to need his expertise, but that is not a reason to follow him down the rabbit hole.

The correct response to discovering the nature of Gradle is to abandon it, immediately. (Similarly Waf, and Scons.) The world does not need yet another one-or-two-language-target build system, or another build system as full general scripting language. Things work better when you don't need expertise. A build system should be just barely powerful enough to do builds, but not powerful enough to mystify. A build system should work equally well for all the languages you might find you need to use. A build system should not need to be studied to be understood: isolated examples should suffice for each need.

Similarly, the build for a project should not need to be understood: everything you need to know about what you are looking at should be right there, or (failing that) in a single, central place for the project. The build should be the least interesting or engaging part of the project; the project itself inevitably demands more attention than you can spare. A build system that demands attention is a child screaming when you need to work.

Many have posted about gradle builds forced on them but I've found modern Gradle to be quite nice. I don't reach for anything too complex - I just list deps and plugins.

Writing new plugins is far easier with Gradle than Maven (and way way way less ugly to configure) and there are more plugins available (and usually of higher quality than their maven counterparts).

Speed is significantly better than Maven. Incremental builds gave us back 80% of our time spent sitting on maven. Reusability is much better than maven too.

There are definite footguns but if you can avoid them (which I understand requires work and itd be better if they were not there at all!) then Gradle is decent. Its no Cargo but woe is life. The few times I had to parse a file at build time to read some credentials in jenkins I've been grateful im using Gradle instead of Maven.

If you work on any seriously big Java/Kotlin/Android project, and value your time, I recommend looking at Buck (or Bazel or other tools) for building instead of Gradle if you haven’t done so yet.

It would be annoying to move build tools, and plenty more of hookups are not as convenient in a bunch if cases, but when you get it going things will run faster. (So again, the bigger the project, the more likely you would like that)

A big part of the reason is that tools suck as Buck (which, like Bazel, uses Skylark as the language, which is a very limited python in essence) avoid the general programming patterns to avoid the issues described here.

The problems match my experience with Gradle pretty well, and they point to a bigger issue in build systems: you usually can't easily debug the build system. Most build systems try to be declarative, but can't help to have imperative parts where order of execution matters or when a certain environment variable is set. You have these kind of problems in Gradle and I experienced them in Cmake, Maven and Make as well. At some point you just want to step-debug or have the environment variables print at a certain point during the build. All I want is a build tool where I declare my build by simply calling functions (or extend with custom functions) and if there's an issue I want to be able to step through the script and check what's wrong.

Many people dont appreciate Maven because they get hung up on XML. If you need to do anything in Maven which isnt dead easy to do in XML you just write a plugin in Java which is the language you are coding in anyway.

Android is the only reason I put up with Gradle, for anything else Java related, I turn to Maven and happily forget that Gradle even exists.

It is Ant all over again, with Groovy slowness and game rig hardware requirements to perform in a sane way. There is hardly any Android conference without build related performance improvement talks.

Can someone explain to me why Gradle is popular? It seems like hot garbage even though most teams can make it work.

Maven was painful as well but it felt more consistent to me.

You know whats really sad? MsBuild proj and solution files are easier to understand!

I'm sure there's a lot of great work that's going into Gradle but I just don't understand why this is the DSL and syntax we decided to put effort into.

Both Maven and Gradle suffer from bad user/developer experience. I think it's partly due to the culture and mindset that Java dictates to its ecosystem. The languages determines our experience, and the experience influences the culture.

I work a lot with gradle and had the same problems in the beginning. I overcome most problems by extending gradle through custom plugins and reading a lot of code. The documentation became clearer and clearer. Granted that is obviously not the desired way of learning a tool. Whenever I talk about Gradle and what it’s biggest problems are it’s exactly that. The introduction docs glance over so many aspects. It gets worse if you are completely new to groovy, Java and gradle. The idea to hide everything behind conventions is smart to keep the amount of configuration low. But if one has no idea about these conventions it becomes insanely hard to figure out how this black box works. One thing I have to disagree is the way he describes how to create tasks and that there are multiple ways of doing it. What he shows is the internal gradle API mainly targeted for plugin authors or gradle itself. There is no barrier. Build script authors should stay away from these APIs to stay forwards compatible with future versions. That’s also why gradle has 3 types of documentation: DSL, API and the raw Java Docs. Again nothing that makes the Tool easier to use for beginners.

It’s not clear to me that Gradle provides any benefit worth the pain it incurs. Every single Gradle file within $COMPANY seems to be completely distinct, with there being god knows how many ways to do something as simple as compiling a Spring application into a jar. I have no idea why each file is different, and which style is the “right” way, or even what the trade offs are.

It’s when I found myself attaching a debugger to my Gradle session to debug it that I threw up my hands in disgust and said “you know what, give me XML back” and went back to Maven.

I'm surpised to see such negative comments. I really enjoy using it - for a build tool that says a lot.

Accomplishing what I thought were standard tasks with Gradle always felt like fragile hacks. The nature of being a younger build system with more API evolution means there are at least 3 ways to do something, without good explanation, and they often can’t be mixed. Maven feels like a build system that I’m configuring. Gradle feels like a piece of software that I’m developing to build my project.

I will say, Gradles files and console output is usually easier on the eyes. And Maven seems to needlessly re-build things when Gradle does not. Still, I want to fiddle with my project, not my build scripts.

If I had to go back to Java tomorrow I would use Gradle hands down. I don't know why the author didn't grok it too well, but for me it has tons of plugins, the scriptability when a plugin is slightly off from what you need, and can be extremely tiny when you just need to build a simple jar.

Make is still popular (not necessarily loved), because it still largely adheres to the Unix philosophy of doing one thing and one thing only. Anything more complex, make it executable and put it on the path and then call it from make.

Gradle. It's a full programming language. And let's not forget there's a ray tracer in pure cmake doing the rounds.

Being cross-platform without having to drop out of the main build tool isn't necessarily a benefit, and that's part of the reason for it's complexity.

When someone does not understand basic tool which is used by most Java developers and that person writes book on that language, that's makes me very surprised. Obviously that person does not have any practical experience with Java, because there's no way you wouldn't stumble onto Gradle or Maven if you're writing real world code in Java.

I guess, that book writing skill is more important in writing good books, than programming skill.

I forked a project [1] in 2015 to remove Gradle, and it then quickly subsumed the original project, remaining under active development to this day.

There were other reasons, but de-gradling was one of the main motivations for my fork, and among the first of the major changes I made. The project is an implementation of an API which was discontinued by the original developers, but initially was built using Maven.

After switching from Gradle (which the project switched to in 2014) back to Maven, build times significantly decreased and development became much more pleasant. I found Gradle to be like a speed bump slowing down development, and reverting back to Maven was like a breath of fresh air. Simple, straightforward, and fast. Maven may not be perfect, but it does the job well.

[1] An open source Bukkit server implementation, https://github.com/GlowstoneMC/Glowstone -> http://github.com/GlowstonePlusPlus/GlowstonePlusPlus

A lot of the complains here remind me of SBT. Makes me dearly mis Maven. I have had a lot of fights with maven, but at least the XML schemas are straightforward. Also strangely all my teams SBT project configs are full of red-underlines in IntelliJ even though they work fine...

Gradle was designed on such shaky foundations, namely Groovy. Let's make build files in an unpopular scripting language with limited tooling ... what could go wrong!

I despise it. XML seemed bad when we had Maven but at least it was a markup language.

I've developed Java for a long time. Ant was at least predictable, though left a lot to be desired. Gradle has always been a tangle of DSL that nobody understands, but just gets copied from random examples and Github repos without any understanding of how or why it works.

Maven is still the best build system I've used in any language or ecosystem. It is predictable, stable, has a great community of plugins, and uses XML as it was meant to be used, which is far better than the JSON / DSL monstrosities I see with newer, "cooler" build tools.

As someone tasked with supporting build and release automation in a large company using Gradle, it's never been enough to learn just enough Gradle and Groovy to build any project, because I learned in a relatively short time that there's no end to all the ways something won't build because of what I didn't know about Gradle or Groovy for a particular build scenario. I also didn't expect to see how a gradle process might behave differently in a Jenkins pipeline job from how it behaves when you run a build interactively at the command line. And least but not last, who would have thought how much of a headache it might be figuring out why an IDE with a Gradle plugin built a project just fine while building with Gradle on the command line or in Jenkins failed.

Some of the issues I eventually figured out had to do with missing or incomplete documentation explaining some of the caveats or gotchas of Gradle constructs that one might assume should work the same way. For example, the use of old-style vs new-style code for plugins (buildscript/apply plugin vs. plugin DSL) is not always interchangeable. The new-style works at the top-level of multiproject builds but one must use the old apply plugin form in subprojects.

We've had to use Gradle to build non-java projects as well, which need to use Exec and Copy tasks to build and stage build artifacts. However, the Copy tasks, which are usually dependent on the Exec build tasks, don't always execute after the tasks they are dependent on have completed. Or rather, a Gradle project built on the command line will successfully respect those dependencies while a Jenkins job will output NO-SOURCE in the task execution step.

The problem with Gradle is that it is not as simple as Make, which I had to use in a prior position. However, successful use of Gradle does require significant more investment in learning more than you first think you might need to know about Gradle in a tutorial. It also requires significant investment in learning about Groovy, which will help illuminate how the Gradle DSL works.

And when gradle fails (which is frequent) your debugging abilities are extremely limited.

For example, someone “donated” a gradle build script to an open source project I help maintain. It lasted less than 6 months before it began breaking, not because we changed stuff, but because gradle updates had changed how some things worked and a plug-in stopped working. Now “obviously” the answer is that we should have pegged the version of gradle required to use the script, but (a) I don’t even know if that’s possible (b) the donator definitely didn’t think to do that (c) who changes such things in such a production level tool during a stable release cycle?

Now the gradle people certainly seem decent, in my interactions with them, but I think there is unfortunately a strong case of Stockholm Syndrome going on there.

Recently I had the pleasure of learning Ruby and then suddenly Gradle started making sense. Things like having more than 1 way to do something, or the magic DSL syntax achieved by using the Ruby unary block syntax - it's a bit more understandable once you learn Ruby.

I know that there are more possibilities now, but back when I was having my first interactions with gradle it was made infinitely harder by groovy and the auto-completion in intellij never working for me.

After years of working with gradle configs, to this day I still don't know groovy or gradle as intimately as I know other things I've spent as much time with. I wish I did, but I just don't.

I can explain to you what our configs do, but if you asked me to make it do something else it'd be straight to google for examples to mangle, a metric tonne of trial and error, and lookups for simple groovy syntax that I keep forgetting in-between the actual work I want to do.

Back in college, I had a summer research internship where the previous year, the interns tried to migrate a large Java code base to Gradle and left it in a broken state. Knowing little more than the Java language at the time, I spent about a month getting Gradle to build it correctly. It was incredibly frustrating not to be able to understand what Gradle was actually doing, instead only copying random lines from example configurations. Almost every time I would fix some errors, new ones would appear with no way to know how close I was to the end.

It’s nice to know that I wasn’t the only one who struggled!

Ohohohoh Gradle. Making Android software turns this into a form of Stockholm syndrome, where you just get used to it. (And as some colleagues go, even pretend to like it. That is, until the next time it does something utterly stupid.) I have spent half a day trying to get a set of tasks to run depending on files that were changed since the original commit that started the git branch. This ought to be simple. Get all the files changed since the start, figure out their modules, figure out modules that have a dependency on those, run the tests only on those modules!

In Gradle-insanity land, you'll need a whole plugin for that. That you have to register in the buildScript.classpath closure. Wait, is it also in the plugins block of the root file ? But maybe also the modules themselves, as an apply. Or is it a plugin block too ? Oh wait, you're using buildSrc ? Well that's a whole other problem. Don't forget you need a basic .properties file in META-INF that just gives out the plugin's name so it can discover it through reflection instead of having a proper API to do so.

You would think the Kotlin scripts instead would fix it, but oh no. Not content with adding a solid 10 seconds every time gradle builds your model (which it rebuilds... Kind of when it feels like it), half of the pretended benefits of it simply do not exist. Almost all the documentation online is for the Groovy scripts, which is, obviously, incompatible with the .kts scripts. And I'm not just talking about syntax, no! Entire APIs are different. Setting a flag like `enabled = true` in groovy ? Have fun, we've added an isEnabled instead, because why not. Registering tasks? Wait, hold on, we've added new solutions in Kotlin! The existing APIs weren't batshit insane already, so let's abuse kotlin delegation. Kotlin's `by lazy {}` is nice and simple, why do we not make your write `val taskName by creating { }` ? And through some horrible logic, the name of your variable is what is exposed to Gradle. Or abusing the same thing for you to read things from a .properties file, because what is more clear than `val isFlagEnabled by project` ? Isn't it obvious that it's going to read a .properties file ? Not the values given through the -P flag when building though, because that would actually make sense. But wait! Let the gradle website explain to you the logic of lazy registered tasks. Why do you need these, you ask? Because Gradle is so absolutely terrible that having a large amount of tasks means they all get created when your daemon starts. Or when it performs anything.

Oh, right, you need a daemon because why would you not need to eat 1GB of RAM just to not have horrible startup times for a build tool? Load all the tasks, at all the times! Add a development flavor to all your modules ? lol you've just doubled your amount of tasks.

Let's add to this of course the absolute insanity that are the Android build tools. Making those work in a Makefile would be hell. aapt2, dexing... An absolute abomination of an amalgamation of bad tools (lol aapt2 silently ignoring your vector drawable overrides because it doesn't like the android:fillType attribute.) and horrible performance (aapt2 taking over a minute to process files on a medium sized project, or kapt (but that's a Kotlin problem) being awful in terms of performance.) All this to output a glorified .zip in the end. Or whatever new format's Google drug addled minds have invented to lock you in further to the Play Store and to make you give them your signing keys.

I am not a fan of Gradle. Or Android's build tools.

Kotlin is great, gradle has improved a lot in the past two years, especially since it supports .kts scripts, but it's still shit. Now, I'm very happy write rust

Gradle's purpose is to make cmake seem palatable.

Cedric Beust made a great alternative to Gradle called Kobalt. Unfortunately, Jetbrains went with Gradle — probably in order to associate Kotlin with a known entity.

Now we are stuck in a terrible situation where step 1 of any java/kotlin project is unpleasant because you have to write a long XML file (Maven) or a magical and incomprehensible build file in groovy/kts (Gradle).

all you need to know about gradle is that there are two phases: configuration and execution. Everything else are details :)

One thing that helped me a lot is to decompile the compiled build script classes with e.g. JADX [1] to see how my code gets turned into Java, since that is what I already knew.

That was my "Ah-ha!" moment in using Gradle.

[1] https://github.com/skylot/jadx

Strong agreement with the author's points. https://cdaringe.github.io/rad/#why-not-my-favorite-build-to... is my less verbose compaction of some of these claims, albeit in tabular format

About point 6, even you don't execute task "a", gradle will still execute the configuration part of it.

I was rather happy with Ant; its tasks were usually 100% spot-on, but scripting them was a PITA and there was no downloading of Jars.

Gradle was easy to start with, but it hides way too many things that end up biting you in the back (sourceSets, anyone?) and those build.gradle files gets way too big.

Too bad there is not much choice.

In my experience Gradle offers great experience only if you understand Groovy closures' "owner" and "delegate" concepts and how Groovy runtime metaprogramming model works. Otherwise you are lost in its magic methods and conventions.

I'm so glad I don't have to deal with Java and it's ecosystem anymore.

Reading this, I'm reminded in many (not good) ways of the .NET build system. Where trivial projects look simple, but once you pull back the curtains there are horrors to behold.

I've found similar problems with all by-convention platforms, like Django and Rails.

Gradle was really not that great back around v3. It was using a ton of my ram, and required frequent cleaning, it was just as bad as Maven in that regard. I think it has improved by lot since then - or maybe thats stockholm syndrome speaking ;) or maybe it's because I stopped doing Android stuff.

In any case, one of the large problems remaining is the bad discovery of stuff-it-can-do-and-how-to-configure-that, and making it too easy for devs to write imperative code when they should be staying declarative.

Also, I don't very much like how complicated some of the newer features are to use, and how much weird magic they require to be turned on / configured.

Another thing I absolutely hate is how it splatters the build scripts into half a dozen files. Personally, even for large monorepos or multi-module builds, I prefer to have one huge script file + plugins.

The strengths of Gradle, if the scripts are written properly, however are very clear to me:

- Task avoidance and therefore crazy good build speedup ofc that requires tasks to be well defined, ideally the whole project to be split up into smaller modules, and each of the build tasks being deterministic. unfortunately many devs don't understand how to do this, and some of the more exotic build steps in monorepos might not be properly deterministic (looking at you, frontend build tools)

- It can be wrapped around other langs and exotic build steps for monorepos. E.g. you can first fire up a database in a container, and run your migrations against that, then use the resulting schema to generate your database entities. In parallel, you might want to run some protobuf generation, that is then used by e.g. a Java backend and a JS frontend built that's actually using yarn in the background. There are plugins available that will wrap the yarn scripts to the Gradle lifecycles. The output of the frontend can be used to be included in the static files of your jar, which you can fire up for tests with browsers running in docker containers and doing e2e tests from the Java BE code, so you can do amazing test setups. Gradle can do all of that, with incremental builds / cached in- and outputs. Imagine having to keep all these steps in your head and running them on-demand when you think its necessary. Or running them every time no matter what (looking at you, Maven) Gradle allows me to write down all of these steps as individual, declarative tasks, making use of a vast and high-quality plugin ecosystem. Then wire up their order, again, declaratively. Once that is accomplished, I can turn off my brain and focus on building code and don't have to know which parts needs to run when exactly.

When I joined one of my previous teams, they were using a rube goldberg machine of Bash, AWK, Python scripts with a lot of JSON slurper and AWK sprinkled in to manage multiple modules in different repos into a monorepo-like state with individual releasing and versioning. With Gradle, that was much easier to accomplish: The dependency resolution rules could be written as simple code with easy and well defined conditionals, instead of manipulation of Maven pom files during random build steps. Also introspection into the build dependencies allowed an easy way to find out which projects dependend in which other ones. (Now was doing all of this a good idea in the first place? probably not :) but they certainly didnt allow themselves to be stopped by Mavens inflexibility, and the resulting horror of a build pipeline was certainly worse then writing all of that in Gradle)

In think, in the end, for small projects, Gradle isn't that benefitial. Maven can accomplish simple builds with no special rules and no necessary task avoidance just as well as Gradle, if not better due to the restrictions. But once you need to build something bigger (did someone say Enterprise?), Gradle starts shining - as long as you tread carefully.

One thing caught my attention on this site: where is the scrollbar (safari iPhone)?

build.sh ftw.

Really? https://melix.github.io/blog/2021/01/the-problem-with-gradle...

> Commands are indented (horribly, by tabs, because make was created in the early days of Unix when they were still obsessed with saving bytes)

See, to me this is exactly not simple (a reference to make’s “simplicity” appears shortly after this). It’s a form of complexity because every time something is wrong with the build, this is one of the things I will need to check.

Moving the complexity elsewhere so that it becomes someone else’s problem just does not work for me as a definition of simplicity. You see this pattern a lot. Golang is pretty much an entire object lesson in this dynamic. Everything is “simple”, aka, “your problem”.

Wanna have hot-lovin' conversations? You’re on the right way! - https://adultlove.life