9 ms·

Gradle still sucks

148 points by andrekandre 4y ago

wiseowise 4y ago
> But goddam it feels like there must be an easier way to accomplish this stuff. Every time articles like that end with this, and yet there’s still no answer.
x-shadowban 4y ago
Gradle is totally undiscoverable. Some autocomplete and goto def would be nice for gradle kts files.
- jpgvm 4y ago
  That should work out of the box with IDEA, just make sure you hit the script sync thing that pops up in the corner.
  - brabel 4y ago
    We have a large Gradle project. IntelliJ just stops keeping track of types and plugins after a certain threshold it seems... our build files are almost all lacking any sort of IDE help... even stuff like String stopped working on some projects, like IntelliJ can't even see it's a Groovy file anymore. Using kts could help but when we built most of it, that didn't exist and when we finally tried, it was so slow and buggy we couldn't use it until maybe a year ago (and we're not going to rewrite thousands of lines of Gradle across multiple projects)... and anyway, Groovy has as much metadata for types as Kotlin as nearly all plugins and Gradle itself use typed Groovy, so this really should work as good in Groovy as in Kotlin. IntelliJ seems to be completely stopping improving the Groovy DSL support, meaning our build will probably become unmaintainable... having had to migrate from Gradle 3 all the way to Gradle 7 over the years, with the many, many breaking changes they've subjected us to over that period, I'd rather rewrite everything in another build system than try to use kts and Gradle 8, which broke even more stuff than previous upgrades.
    - rhdunn 4y ago
      The best thing to do here is to check the IntelliJ bug tracker (https://youtrack.jetbrains.com/issues/IDEA https://youtrack.jetbrains.com/issues/IDEA) to see if your issue is there, and if not create a ticket for it. That way, it is more likely to be fixed.
- wiseowise 4y ago
  Just write a goddamn plug-in. Seriously, this is an open secret of Gradle pros.
turtleyacht 4y ago
My ideal approach to Gradle would be reading every User Manual [1] starting from v0.7 [2]. But not even an entire workweek is enough for that kind of meditative study. As a comparison, building Java with make: https://www.oreilly.com/openbook/make3/book/ch09.pdf https://www.oreilly.com/openbook/make3/book/ch09.pdf [PDF] From Managing Projects with GNU Make 3e (2004) by Robert Mecklenburg [1] https://gradle.org/releases https://gradle.org/releases [2] https://docs.gradle.org/0.7/userguide/userguide.html https://docs.gradle.org/0.7/userguide/userguide.html
zeedude 4y ago
A general purpose language as the basis for a build tool always felt like a sledgehammer/nail situation to me. Personally, I prefer less concise, less flexible build config tooling.
- sofixa 4y ago
  Agreed, and I think the same applies in multiple other domains. A general purpose language for CI/CD configuration (Groovy), Infrastructure as Code (Pulumi) is just giving you enough flexibility to shoot yourself in the foot while making reusability and readability much more of a problem than it needs to be. I hate YAML for anything more complex than a flat configuration file but I'd take it over Groovy any day.
alex_lav 4y ago
> During my period of intense frustration with Gradle I found this condescending blog post claiming that anyone who dislikes it is simply using it wrong. Replace Gradle with literally any tech tool and you'll find the same articles. A hill that I'll gladly die on is that Git sucks, maybe more than any other tool so widely adopted, and yet bringing up how badly it sucks usually results in a deluge of downvotes and "No! You don't understand! Just learn the internals of the tool!" and "Oh yeah well if it's so bad, what do you suggest?!" I reject this sentiment. I don't have to have all the answers to point out that something sucks. I also shouldn't be expected to learn the inner workings of a tool that we expect code school students to use. > But that’s stupid. When I took a step back I realized that all of the problems I had with Gradle before still existed, I just understood how to use them to get work done. But the fundamental problem with Gradle is that it simply does not justify these complexities. Yep. Spot on. > But goddam it feels like there must be an easier way to accomplish this stuff. I've done multiple forays into Java and always fall into the trap of "Certainly in <insert year> java tooling must not suck as bad?" but I come up empty. It still sucks. A real mess. I really enjoyed this blog post.
- fbdab103 4y ago
  I am just smirking that within seven minutes, the git supporters are appearing.
  - dvh 4y ago
    Git may suck but it suck fast! Alternatives sucks as well but are also slow.
- henry2023 4y ago
  Curious question: why do you think git sucks? From my perspective is one of the fundamental tools behind modern software engineering. brilliantly designed and yet so simple to use. I’ll even go ahead of myself to believe you’d be able to make a successful tech company just providing a “git for X” where X is another industry
  - 4y ago
larusso 4y ago
I work with gradle for the better part of 5 years and use it to build Unity projects. I wrote multiple custom plugins and maintain them still. Learning how gradle works was hard. The official docs didn’t help in the beginning. I only know how to author build scripts because I spend a lot of time in the internals. I don’t use many third party plugins because they never 100% work as intended and become a liability later on when a gradle update is needed. But do I think it is too complicated and abstract? Yes and No. The main problem is that gradle contains a load of old Bagage. Most concepts which are still in the product center around lazy evaluation and to decouple the what from how. The introduction of Providers a couple of years ago was a pivotal point. Writing lazy evaluated scripts was only possible through private methods which used groovy magic to implement this. I never saw a build system or build tool be just simple when the desired outcome is decoupled and fast builds. Would I pick gradle today? I guess not. But I still think it is a great tool. I looked at nix and hazel and these tools are also not simple.
jpgvm 4y ago
So I went through this stage too but I stuck it out to pass through to the other side. Mostly because the options weren't any better. Gradle's main problem is that it doesn't have a learning curve, it has a learning cliff. You either understand it or you don't and that is terrible for adoption and for people trying to get it like this fellow. What lies beyond this stage is understanding that these things -are- actually complex for a reason. Attempting to create something simpler just for your "simple" use case eventually requires you to add more stuff to do some new thing and before you know it you have a shitty version of Gradle instead of normal Gradle with some custom plugins/tasks/whatever you happen to need. That said I'm in the process of going deep on Bazel because Gradle still falls short of the mark for me. Bazel has more of an actual learning curve, it's peak complexity is lower than Gradle (though mostly because it's offloaded that complexity into rulesets). The reality is that these build systems are hard because they are designed to solve very hard problems when you are building programs with lots of artefacts at big scale where very fine grained caching isn't just nice to have but imperative in order to actually do builds at a reasonable cadence. Appreciation of these systems is tightly coupled to -actually- having those problems. If you don't have those problems you probably don't get why these things are so complicated/baroque/alien/whatever they may seem to you. In Gradle's case you can generally build a bunch of JVM code without really understanding Gradle. I consider this to be a bit of a trap but I get -why- it's like this which is that it would simply have no adoption if everyone had to understand the phases, source sets, etc but I still don't like copy/paste builds all the same. Bazel is both slightly better and slightly worse in this regard. You need to understand some more Bazel concepts to build anything at all - which I consider a good thing, understanding vs copy-paste is good in my book. However that understanding is a bit of an illusion once you realise you need something with a modicum of more complexity. Soon you will open up a ruleset and realise that for instance the inbuilt rules_java is actually lugging around this JavaInfo thing and rules that are "java aware" are doing things with this rather than "just artefacts" as your simple understanding was let you to believe etc. Most programmers don't give build systems that respect they deserve. They want them to just work and be out of their way, mostly because they don't care how their artefacts get built. I think this is both wrong and sad but I also don't see it changing, too many incentives to not care as long as it builds. Meaning that understanding of real build systems is concentrated on a small number of individuals at a few places big enough to need them.
eitland 4y ago
At a previous project I decided to start fresh, swallow my pride and become friends with Gradle. Everyone of the cool Gradle guys can't be wrong, right? There must just be something that hasn't "clicked" for me yet. As part of the process I analyzed some builds that used Gradle. It is a while ago now, but I think for something like 24 builds, I found 21 different ways to do it. Kotlin, Groovy and whether to use constants or not were just the beginning. Constants can be extracted and with a little help of DDG, every file can be updated to its kts version. But that is just the beginning. It seems to be a rule that every single thing must be possible to do in at least two different ways. I came out of that process convinced that, no, for most ordinary projects a lot of precious time can be saved by using Maven despite the "uglyness" of the pom. Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. Everytime I see the "elephant balancing on the ball" illustration that is sometimes used for Gradle courses I chuckle for myself and think it is perfect: It is a impressive, but one tiny mistake away from collapsing and breaking something big time.
- creatonez 4y ago
  > Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. I experienced the opposite, that even simple things require quite complex configuration in maven. I was shocked by how difficult shading is. Gradle and SBT gave some confusion, but a great deal less than maven.
  - eitland 4y ago
    > even simple things require quite complex configuration in maven. I have used Maven on and off since around 2007/2008 sometime. Since I started taking responsibility for build setups I have realized that I think in every single case where I found unexpected complexity in Maven it could be solved by something like putting some folder or file in the place it was supposed to be all the time and delete most of the configuration. Convention over configuration is central to Maven after all and extra configuration is only necessary if you do something non standard.
bedatadriven 4y ago
I work with a large project built with gradle that includes a lot of custom code generation and other automation very specific to our project. Strong disagree with this article. One thing that makes my gradle experience more pleasant I think is that I assiduously avoid plugins, and just write the meat of my tasks in Java. Adding a new source set is a one-liner, then just put your code generation logic in src/generator/java. Add a JavaExec task to run your main class and, optionally define inputs and outputs to enable up-to-date checking. Painless, simple, powerful. Here's an example: https://gist.github.com/akbertram/1d543c8648ddf322f9866c373877b04f https://gist.github.com/akbertram/1d543c8648ddf322f9866c3738...
ChuckMcM 4y ago
"Concept overload motivates abstraction and that can obfuscate understanding." I'm not sure who said that but I wrote it down a long time ago and use it to remind me about making things both simple and understandable.
pjmlp 4y ago
After Grails lost its steam, Gradle only matters because Android team made it unavoidable. Gradle is Ant re-invented by those that didn't learn why we moved away from Ant.
- singularity2001 4y ago
  Gradle is the single biggest reason why I hate Android Studio and shun away from Kotlin, despite it being a beautiful language (and usually loving Intellij)
  - wiseowise 4y ago
    Why?
  - kaba0 4y ago
    You have it reversed - android doing a million things making gradle sweat gives gradle a bad name. But show me any build tool that could replace gradle in its role in android development.
    - shaftway 4y ago
      Google uses blaze to build the vast majority of Android apps internally. Anything that's not checked into the AOSP repos.
    - singularity2001 4y ago
      No, even simple Kotlin projects become annoying quickly due to gradle.
      - wiseowise 4y ago
        Can you provide one example?
- oweiler 4y ago
  Sadly, it has become the de-facto standard for Kotlin projects in general.
crop_rotation 4y ago
For personal java/kotlin projects I just use IntelliJ for building. Things are much simpler and it is easy to do most things. My biggest problem with gradle on personal macs is that memory hog daemon that is mostly unavoidable. Just to run a build once in a while I don't want to run a daemon. Yes daemon can be turned off but it is prevalent in the ecosystem and IntelliJ gradle integ doesn't work without it. Gradle makes me appreciate how good both cargo is.
- marginalia_nu 4y ago
  Yeah I get where you're coming from. The daemon is pretty sweet in reducing build times, but I wish there was some easy way of informing it of your intent. If you're just a casual drive-by person compiling some code, then spawning a gradle daemon is just silly. If you're actively developing on a codebase, not having a gradle daemon will waste a lot of time waiting on builds that could be instant.
huodon 4y ago
sbt, gradle has left me with bad memories, working on jvm is a stain on my life
- tasuki 4y ago
  Used to use sbt at work, then someone came in with the idea that we should migrate to gradle. To be fair to them, they did most of the migration work by themselves, which was impressive. I haven't really noticed any improvement, just that some workflows I was used to with sbt stopped being available.
berkle4455 4y ago
Just stop wasting time with Java and any of its many derivatives. Leave it where it belongs: poorly educating students in uni with terrible OOP practices that’ll take 5-10 years to unwind.
jillesvangurp 4y ago
Most build systems have their idiosyncrasies. I do a lot of Kotlin (on server, multi platform, and browser), so I've been an early adopter for the kts dialect. I've used maven and ant in the past on the jvm. And off the jvm things like make, webpack, and other things. And of course lots of configuration language tools (puppet, chef, ansible) as well as things like travis, jenkins, and Github actions. So, I know my tools. And occasionally love to hate them. Most of these tools have stuff they are good at and stuff that while they can technically can do they just aren't the best tool for. Things I don't like about gradle: - the whole (kotlin scripting) kts vs. groovy split. IMHO groovy makes things harder at this point and more poorly discoverable. And because the kotlin scripting part has to be sort of compatible with the groovy part you are left with auto completion that works poorly because of the multiple unnecessary levels of indirection that comes in via the groovy centric internals. This has been improving slowly over the years. At least for new projects, kts is now the default (in Android studio). - all the "maybe this will work" performance hacks that the gradle people built into their tool over the years. You get lots of complexity from layers of caching, daemons, half working offline modes, etc. They work a little bit but the multiple layers of hacks, outdated feature flags, etc. are annoying. - regular compatibility breaking changes that mean suddenly your build no longer works on a major version change. "we changed our mind, again, about how stuff is supposed to work" and please be fixing all your build files. The how bit is typically left as a hunt through bad documentation. - the maze of misdirection that is the documentation and the collective body of unhelpful stackoverflow posts and other online articles. Which thanks to regular compatibility breaking changes and the switch to kts tends to be groovy centric and hopelessly outdated. A lot of the "solutions" you find either don't work at all due to this or needs to be translated. Anything over two years old is probably wrong at this point. It's that bad. On a positive note, it does work once you get it dialed in. And I tend to not mess with my build files too much. If it looks like a shell script, I'm not even going to attempt doing it from gradle. I'll automate via github actions rather than gradle. Just easier. And while kts is a PITA to deal with in intellij (it freaks out regularly over phantom compile errors for no good reason whatsoever until you turn it off and on again), having auto completion helps. And being able to use regular kotlin to do stuff is also helpful. But doing simple things is still way too hard. Mostly I stick with gradle because it is the path of the least resistance. It's the thing that is supported by world + dog, probably the most likely thing to be documented, and others sort of expect it at this point. Everything else is more work to figure out and set up.
rickette 4y ago
For your typical run of the mill project just stick to Maven. The fact that it uses an XML file is not a real issue in any way shape or form.
shaftway 4y ago
I work on a large codebase that uses Gradle. We're occasionally held up as an example: "see? This corp uses Gradle for something this large, so it must be good." We have a regularly scheduled meeting with Gradle where we have in the past influenced their feature prioritization. We also have a former Gradle engineer on staff. Gradle is such garbage. I can't count the number of times our ex-Gradler has said "you're not going to like the answer..." Everything is action-at-a-distance and implicit. You can't answer basic questions like: - Why does this task exist? - Why does this task depend on this other task? - Why did this file get included or excluded? - How did I get 4 dependencies on 4 different versions of the same library? You can't answer this stuff because some random include file in some random place reached into a task that had already been created and modified it. And there's no way to find out where this happened. I don't understand why you would want a build system that has build tasks that are mutable. And yes, it would be nice if people wouldn't do action-at-a-distance, or would not do weird stuff to tasks after they've been created, but that's not really possible. We've actually gone through the trouble of writing a linter that makes sure that devs aren't doing anything too crazy in their .gradle files. But of course some files have to do crazy stuff, so there's an escape hatch, so everyone just uses that.
- kaba0 4y ago
  > that has build tasks that are mutable They are not mutable.. their configuration is. That’s like the whole point of gradle. Also, people should just learn to write plugins - that’s the proper way to add functionality.
  - wiseowise 4y ago
    Don’t know why this is downvoted when it’s the truth. Build scripts are there to just configure stuff. Gradle is literally combination of tasks, plug-ins and artifacts.
    - Jolter 4y ago
      Then maybe Gradle should do what Maven does and disallow writing code in the configuration?
RamblingCTO 4y ago
While Gradle sucks and is complex af I really do like multi-module stuff. We can flesh out components that are intertwined, test them separately and things like that. So if you have a big backend that wouldn't make sense as microservices it really do helps. I haven't seen any other build tools that allow me to build multi-module stuff. Anyone?
- piva00 4y ago
  Maven? I've worked on quite a few large backend projects using multi-module in Maven, after it's setup it works: parent POM, submodules, dependency management on parent POM. It depends on what features specifically you are looking for though.
  - RamblingCTO 4y ago
    I didn't know that. For me the biggest block is XML to be honest. I really dig kotlin in that regard.
    - piva00 4y ago
      XML is just verbose, after that it's pretty simple. It's all declarative, there's no code execution during build time that you have to keep in mind to build a mental model of what is actually executing, you read the XML, check the steps and configurations and can understand completely what's being executed. I like Kotlin, I don't like build tools that allow general computing during runtime where I will have to debug build code to understand what exactly has failed. Declarative tools are much better to reason about for most infrastructure tasks.
kaba0 4y ago
The author of this blog has been cutting the branch they’re sitting on, making the whole ordeal orders of magnitude more complex then it should be. With that said, Gradle’s official documentation is indeed bad and the necessary working model is hard to figure out, but that model is sound, and is necessary complexity for solving the general problem of dependency management. The problem is that there is a discrepancy between “download this and that dependency and run it” hobby projects, and the monstrosities that have to exist in large projects. Gradle is a general build tool, it could be used for multiple languages even. The well liked Cargo is of course much more user friendly, but it simply couldn’t be used as a general build tool, so it sheds a lot of weight there.
nitwit005 4y ago
Steps 2 to 10 are creating a plugin, and some later steps are a consequence of creating plugin subprojects, but I'm not sure why that was needed? From their description, the plugin just runs some things on the command line. Isn't this the most boring form of code generation?
tarkin2 4y ago
The RAM usage of the daemon, the fact there are two programming language you can write it in, and you’re often reading documentation based on the other language, with the newer language slowing down already slow, slow build times, the ever changing syntax, the abstractions, caching problems, the fact the build system is significantly more complex than 99% of anything it’ll ever build, makes writing bash scripts look appealing again.
- kaba0 4y ago
  What caching problem? Gradle really is correct in this regard (compared to Maven), it is likely some plugin that might cause troubles for you, which is not something Gradle can defend against. > the fact the build system is significantly more complex than 99% of anything it’ll ever build This is the real problem of Gradle — but is their any other tool for that 1%? Because it is definitely not any of the well-liked language specific ones like Cargo. Build tools are a hard problem.
  - tarkin2 4y ago
    How many times have you just deleted the build folder to fix things? I use bash for my personal projects now. Thankfully I need none of the advanced features gradle provides/inflicts upon you.
    - kaba0 4y ago
      Never. And bash is an abomination, I would much rather use brainfuck :D
microflash 4y ago
I've tried Gradle again and again only to go back to Maven. Gradle is painfully slow on large (and even small) builds. It's backward compatibility story is non-existent. You can pick any two build files and chances are that they are completely different when compared. Groovy dialect has poor autocompletion support. Maven, on the other hand, has been extremely fast (with or without caching). I've been upgrading Maven for a long time and have yet to see an upgrade that breaks the build. I can pick any two POM files and chances are they are almost identical. XML, for all it's deficiencies, absolutely flies when it comes to autocompletion. My experience has been same from small projects to large multi-module projects.
- kaba0 4y ago
  Gradle is much faster than maven, as it supports parallel builds, has much smarter caching/evaluation strategies, etc. You just likely have tasks run at configuration time (you don’t use doFirst/doLast in custom tasks), or some other problematic build files.
  - microflash 4y ago
    This reinforces my opinion about Gradle: there are too many footguns and papercuts. Every time I shot myself in foot using Gradle, some Gradle expert would chime in that I'm probably not using some (poorly documented) way of doing things that would have drastically improved my experience. This becomes even more problematic in large teams where we have a mix of experienced and novice engineers. Onboarding new people and maintaining the cognitive load about the build using Maven is several magnitudes faster and predictable than with Gradle.
  - pjmlp 4y ago
    By requiring an always running background daemon to actually make it fast.
    - kaba0 4y ago
      No, gradle is fast in CICD settings as well where daemons are meaningless. It is fast because it has a proper graph model that only updates nodes that need to be updated, and can often do so in parallel.
amir734jj 4y ago
I'm not a Java guy, but Maven is much easier to learn but I have found some people in Java world religiously love Gradle. I don't know what is it with jvm language build tools ... Ehem sbt.
MrDresden 4y ago
I have been using Gradle for more then a decade and for the most part it works fine but occasionally there are situations where I have no clue what went wrong. Onboarding junior developers onto a big multi module projects that use Gradle can be really difficult. Understandably they are unable to grok the mental model (sometimes I even doubt if I do after all this time). One thing that has helped though has been switching entirely over to the Kotlin DSL.
smitty1e 4y ago
I got to the end of the article and realized that Gradle is "el drag" spelled backward. At that level of suffering, it sounds as though one has crafted a custom build tool for each non-trivial project.
naruhodo 4y ago
I love good rant and this one sent me into paroxysms of delight! About 9 out of 10 gradle build configurations that I have encountered fail to build something. That's surprising, and infuriating given that: * Gradle is based on a portability layer, the JVM. * Gradle competes against a portable and relatively reliable build system, Maven, and competes against make, which is non-portable due to its use of the system shell for arbitrary code. I would take Maven or make over Gradle any way of the week. I have one other major beef with Gradle: every single Gradle-based project I have encountered on GitHub includes the Gradle JAR file. The author wants me to download and execute arbitrary Java code without even the option of inspecting it! To hell with that! I had a breakthrough with Gradle recently: Gradle builds that fail on my Fedora laptop work just fine in an Ubuntu "toolbox" container. So much for portability! Like the author of the article, I have devoted several (not as many) hours to understanding Gradle. It is largely incomprehensible, when encountered in the wild.
- miskin 4y ago
  You do not need to use the gradle wrapper - you can use your own trusted version. Wrapper is there just for convenience. I understand your concerns, but it is not the only way and you are not forced to use it.
  - naruhodo 4y ago
    I actually have tried to use the trusted version that comes with the Fedora packages. It was quite a while ago so I don't remember exactly why that didn't work, but I think it had to do with Fedora packaging an older version of Gradle than the build configuration required. So, nice thought. I guess I could work out what Ubuntu system the author used and set up a matching Ubuntu toolbox (container) with the right Gradle version. It's not really a win for Gradle if the developer's operating system has to be shipped with the build system.
  - shaftway 4y ago
    Except that Gradle constantly releases new versions with breaking changes. You need to install your own trusted version for each version that you use, and know which one to use for each project.
cryptos 4y ago
There is more than Maven and Gradle. Maybe a new build tool callded "bld" could make life a bit easier: https://rife2.com/bld https://rife2.com/bld
- piva00 4y ago
  Why would I choose yet-another-build-tool if Maven works, is stable and backwards compatible? Even worse, why I would choose Java as my language to run a build? The only benefit is to avoid learning a tool that isn't Java, there's nothing else to it. For some Java build tool to actually gain traction it'd need to be better than Maven in every way, that's pretty hard to accomplish and I'd say that starting a tool that runs code already goes against the best practices for infrastructure code: convention-over-configuration, declarative.
bfrog 4y ago
Reason 101 why android studio and development is a horror show.
AtlasBarfed 4y ago
"modern, idiomatic, as-God-intended method of Gradle usage" Which changes literally every release, and half of my gradle tasks (already cobbled-together voodoo incantations) for shaded jars, dependency copying, integration tests, etc ... as in common tasks for build systems ... breaks. That said, building is HARD, and man is it HARD to pick up the nuances. Really there should be a massive standard feature set for build frameworks that every build framework has to document an example of. Ant was too XML-y, and too disorganized. Then came Maven (still XML-y) but way too rigid and limited. Then came gradle, which had potential, but largely is a failure. Gradle is well supported by IntelliJ. That's why it's the choice currently. I tried IntelliJ with Maven and it failed with some basic stuff, so it's gradle or ... nothing. The caveat, again, is that, like languages, there are two types of build systems: those you complain about (because you use them) and those that aren't used at all. I have not used bazel, pants, or any of the newer build frameworks. Make is both zealously pushed by neckbeards, but curiously used almost nowhere outside of C (a bad sign) and I've read really good "make sucks because" posts. It speaks to the general constant cycle of suck in software that building code, something that we've done in software for a half-century plus, has very little to show in the way of evolution and growth. But that's because there is nobody that has proper economic investment incentives. Even google probably underfunds Bazel. I almost wonder why google and those places don't have two groups / virtual companies that compete to be the build system based on project usage (I also wonder why large companies with a dozen datacenters don't have them compete against each other internally for customers / project funny money).
CmdrLoskene 4y ago
So Gradle is not a build tool, it's a tool for building build tools? That's wonderful, but that's not what I want. I am trying to solve problems in my particular domain. I want to spend my time solving those problems, not wrestling with my tool for building build tools. I just want a tool which knows how to build my things, given the dependencies I give it. I want a tool with clear and up-to-date documentation. I want a tool whose behavior I can reason over. Is that too much to ask? Apparently, for gradle, it's too much to ask.

148 points by andrekandre 4y ago

> But goddam it feels like there must be an easier way to accomplish this stuff. Every time articles like that end with this, and yet there’s still no answer.

x-shadowban 4y ago

Gradle is totally undiscoverable. Some autocomplete and goto def would be nice for gradle kts files.

jpgvm 4y ago
That should work out of the box with IDEA, just make sure you hit the script sync thing that pops up in the corner.
- brabel 4y ago
  We have a large Gradle project. IntelliJ just stops keeping track of types and plugins after a certain threshold it seems... our build files are almost all lacking any sort of IDE help... even stuff like String stopped working on some projects, like IntelliJ can't even see it's a Groovy file anymore. Using kts could help but when we built most of it, that didn't exist and when we finally tried, it was so slow and buggy we couldn't use it until maybe a year ago (and we're not going to rewrite thousands of lines of Gradle across multiple projects)... and anyway, Groovy has as much metadata for types as Kotlin as nearly all plugins and Gradle itself use typed Groovy, so this really should work as good in Groovy as in Kotlin. IntelliJ seems to be completely stopping improving the Groovy DSL support, meaning our build will probably become unmaintainable... having had to migrate from Gradle 3 all the way to Gradle 7 over the years, with the many, many breaking changes they've subjected us to over that period, I'd rather rewrite everything in another build system than try to use kts and Gradle 8, which broke even more stuff than previous upgrades.
  - rhdunn 4y ago
    The best thing to do here is to check the IntelliJ bug tracker (https://youtrack.jetbrains.com/issues/IDEA https://youtrack.jetbrains.com/issues/IDEA) to see if your issue is there, and if not create a ticket for it. That way, it is more likely to be fixed.
wiseowise 4y ago
Just write a goddamn plug-in. Seriously, this is an open secret of Gradle pros.

turtleyacht 4y ago

My ideal approach to Gradle would be reading every User Manual [1] starting from v0.7 [2]. But not even an entire workweek is enough for that kind of meditative study. As a comparison, building Java with make: https://www.oreilly.com/openbook/make3/book/ch09.pdf https://www.oreilly.com/openbook/make3/book/ch09.pdf [PDF] From Managing Projects with GNU Make 3e (2004) by Robert Mecklenburg [1] https://gradle.org/releases https://gradle.org/releases [2] https://docs.gradle.org/0.7/userguide/userguide.html https://docs.gradle.org/0.7/userguide/userguide.html

zeedude 4y ago

A general purpose language as the basis for a build tool always felt like a sledgehammer/nail situation to me. Personally, I prefer less concise, less flexible build config tooling.

sofixa 4y ago
Agreed, and I think the same applies in multiple other domains. A general purpose language for CI/CD configuration (Groovy), Infrastructure as Code (Pulumi) is just giving you enough flexibility to shoot yourself in the foot while making reusability and readability much more of a problem than it needs to be. I hate YAML for anything more complex than a flat configuration file but I'd take it over Groovy any day.

alex_lav 4y ago

> During my period of intense frustration with Gradle I found this condescending blog post claiming that anyone who dislikes it is simply using it wrong. Replace Gradle with literally any tech tool and you'll find the same articles. A hill that I'll gladly die on is that Git sucks, maybe more than any other tool so widely adopted, and yet bringing up how badly it sucks usually results in a deluge of downvotes and "No! You don't understand! Just learn the internals of the tool!" and "Oh yeah well if it's so bad, what do you suggest?!" I reject this sentiment. I don't have to have all the answers to point out that something sucks. I also shouldn't be expected to learn the inner workings of a tool that we expect code school students to use. > But that’s stupid. When I took a step back I realized that all of the problems I had with Gradle before still existed, I just understood how to use them to get work done. But the fundamental problem with Gradle is that it simply does not justify these complexities. Yep. Spot on. > But goddam it feels like there must be an easier way to accomplish this stuff. I've done multiple forays into Java and always fall into the trap of "Certainly in <insert year> java tooling must not suck as bad?" but I come up empty. It still sucks. A real mess. I really enjoyed this blog post.

fbdab103 4y ago
I am just smirking that within seven minutes, the git supporters are appearing.
- dvh 4y ago
  Git may suck but it suck fast! Alternatives sucks as well but are also slow.
henry2023 4y ago
Curious question: why do you think git sucks? From my perspective is one of the fundamental tools behind modern software engineering. brilliantly designed and yet so simple to use. I’ll even go ahead of myself to believe you’d be able to make a successful tech company just providing a “git for X” where X is another industry
- 4y ago

larusso 4y ago

I work with gradle for the better part of 5 years and use it to build Unity projects. I wrote multiple custom plugins and maintain them still. Learning how gradle works was hard. The official docs didn’t help in the beginning. I only know how to author build scripts because I spend a lot of time in the internals. I don’t use many third party plugins because they never 100% work as intended and become a liability later on when a gradle update is needed. But do I think it is too complicated and abstract? Yes and No. The main problem is that gradle contains a load of old Bagage. Most concepts which are still in the product center around lazy evaluation and to decouple the what from how. The introduction of Providers a couple of years ago was a pivotal point. Writing lazy evaluated scripts was only possible through private methods which used groovy magic to implement this. I never saw a build system or build tool be just simple when the desired outcome is decoupled and fast builds. Would I pick gradle today? I guess not. But I still think it is a great tool. I looked at nix and hazel and these tools are also not simple.

jpgvm 4y ago

So I went through this stage too but I stuck it out to pass through to the other side. Mostly because the options weren't any better. Gradle's main problem is that it doesn't have a learning curve, it has a learning cliff. You either understand it or you don't and that is terrible for adoption and for people trying to get it like this fellow. What lies beyond this stage is understanding that these things -are- actually complex for a reason. Attempting to create something simpler just for your "simple" use case eventually requires you to add more stuff to do some new thing and before you know it you have a shitty version of Gradle instead of normal Gradle with some custom plugins/tasks/whatever you happen to need. That said I'm in the process of going deep on Bazel because Gradle still falls short of the mark for me. Bazel has more of an actual learning curve, it's peak complexity is lower than Gradle (though mostly because it's offloaded that complexity into rulesets). The reality is that these build systems are hard because they are designed to solve very hard problems when you are building programs with lots of artefacts at big scale where very fine grained caching isn't just nice to have but imperative in order to actually do builds at a reasonable cadence. Appreciation of these systems is tightly coupled to -actually- having those problems. If you don't have those problems you probably don't get why these things are so complicated/baroque/alien/whatever they may seem to you. In Gradle's case you can generally build a bunch of JVM code without really understanding Gradle. I consider this to be a bit of a trap but I get -why- it's like this which is that it would simply have no adoption if everyone had to understand the phases, source sets, etc but I still don't like copy/paste builds all the same. Bazel is both slightly better and slightly worse in this regard. You need to understand some more Bazel concepts to build anything at all - which I consider a good thing, understanding vs copy-paste is good in my book. However that understanding is a bit of an illusion once you realise you need something with a modicum of more complexity. Soon you will open up a ruleset and realise that for instance the inbuilt rules_java is actually lugging around this JavaInfo thing and rules that are "java aware" are doing things with this rather than "just artefacts" as your simple understanding was let you to believe etc. Most programmers don't give build systems that respect they deserve. They want them to just work and be out of their way, mostly because they don't care how their artefacts get built. I think this is both wrong and sad but I also don't see it changing, too many incentives to not care as long as it builds. Meaning that understanding of real build systems is concentrated on a small number of individuals at a few places big enough to need them.

eitland 4y ago

At a previous project I decided to start fresh, swallow my pride and become friends with Gradle. Everyone of the cool Gradle guys can't be wrong, right? There must just be something that hasn't "clicked" for me yet. As part of the process I analyzed some builds that used Gradle. It is a while ago now, but I think for something like 24 builds, I found 21 different ways to do it. Kotlin, Groovy and whether to use constants or not were just the beginning. Constants can be extracted and with a little help of DDG, every file can be updated to its kts version. But that is just the beginning. It seems to be a rule that every single thing must be possible to do in at least two different ways. I came out of that process convinced that, no, for most ordinary projects a lot of precious time can be saved by using Maven despite the "uglyness" of the pom. Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. Everytime I see the "elephant balancing on the ball" illustration that is sometimes used for Gradle courses I chuckle for myself and think it is perfect: It is a impressive, but one tiny mistake away from collapsing and breaking something big time.

creatonez 4y ago
> Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. I experienced the opposite, that even simple things require quite complex configuration in maven. I was shocked by how difficult shading is. Gradle and SBT gave some confusion, but a great deal less than maven.
- eitland 4y ago
  > even simple things require quite complex configuration in maven. I have used Maven on and off since around 2007/2008 sometime. Since I started taking responsibility for build setups I have realized that I think in every single case where I found unexpected complexity in Maven it could be solved by something like putting some folder or file in the place it was supposed to be all the time and delete most of the configuration. Convention over configuration is central to Maven after all and extra configuration is only necessary if you do something non standard.

bedatadriven 4y ago

I work with a large project built with gradle that includes a lot of custom code generation and other automation very specific to our project. Strong disagree with this article. One thing that makes my gradle experience more pleasant I think is that I assiduously avoid plugins, and just write the meat of my tasks in Java. Adding a new source set is a one-liner, then just put your code generation logic in src/generator/java. Add a JavaExec task to run your main class and, optionally define inputs and outputs to enable up-to-date checking. Painless, simple, powerful. Here's an example: https://gist.github.com/akbertram/1d543c8648ddf322f9866c373877b04f https://gist.github.com/akbertram/1d543c8648ddf322f9866c3738...

ChuckMcM 4y ago

"Concept overload motivates abstraction and that can obfuscate understanding." I'm not sure who said that but I wrote it down a long time ago and use it to remind me about making things both simple and understandable.

pjmlp 4y ago

After Grails lost its steam, Gradle only matters because Android team made it unavoidable. Gradle is Ant re-invented by those that didn't learn why we moved away from Ant.

singularity2001 4y ago
Gradle is the single biggest reason why I hate Android Studio and shun away from Kotlin, despite it being a beautiful language (and usually loving Intellij)
- wiseowise 4y ago
  Why?
- kaba0 4y ago
  You have it reversed - android doing a million things making gradle sweat gives gradle a bad name. But show me any build tool that could replace gradle in its role in android development.
  - shaftway 4y ago
    Google uses blaze to build the vast majority of Android apps internally. Anything that's not checked into the AOSP repos.
  - singularity2001 4y ago
    No, even simple Kotlin projects become annoying quickly due to gradle.
    - wiseowise 4y ago
      Can you provide one example?
oweiler 4y ago
Sadly, it has become the de-facto standard for Kotlin projects in general.

crop_rotation 4y ago

For personal java/kotlin projects I just use IntelliJ for building. Things are much simpler and it is easy to do most things. My biggest problem with gradle on personal macs is that memory hog daemon that is mostly unavoidable. Just to run a build once in a while I don't want to run a daemon. Yes daemon can be turned off but it is prevalent in the ecosystem and IntelliJ gradle integ doesn't work without it. Gradle makes me appreciate how good both cargo is.

marginalia_nu 4y ago
Yeah I get where you're coming from. The daemon is pretty sweet in reducing build times, but I wish there was some easy way of informing it of your intent. If you're just a casual drive-by person compiling some code, then spawning a gradle daemon is just silly. If you're actively developing on a codebase, not having a gradle daemon will waste a lot of time waiting on builds that could be instant.

huodon 4y ago

sbt, gradle has left me with bad memories, working on jvm is a stain on my life

tasuki 4y ago
Used to use sbt at work, then someone came in with the idea that we should migrate to gradle. To be fair to them, they did most of the migration work by themselves, which was impressive. I haven't really noticed any improvement, just that some workflows I was used to with sbt stopped being available.

berkle4455 4y ago

Just stop wasting time with Java and any of its many derivatives. Leave it where it belongs: poorly educating students in uni with terrible OOP practices that’ll take 5-10 years to unwind.

jillesvangurp 4y ago

Most build systems have their idiosyncrasies. I do a lot of Kotlin (on server, multi platform, and browser), so I've been an early adopter for the kts dialect. I've used maven and ant in the past on the jvm. And off the jvm things like make, webpack, and other things. And of course lots of configuration language tools (puppet, chef, ansible) as well as things like travis, jenkins, and Github actions. So, I know my tools. And occasionally love to hate them. Most of these tools have stuff they are good at and stuff that while they can technically can do they just aren't the best tool for. Things I don't like about gradle: - the whole (kotlin scripting) kts vs. groovy split. IMHO groovy makes things harder at this point and more poorly discoverable. And because the kotlin scripting part has to be sort of compatible with the groovy part you are left with auto completion that works poorly because of the multiple unnecessary levels of indirection that comes in via the groovy centric internals. This has been improving slowly over the years. At least for new projects, kts is now the default (in Android studio). - all the "maybe this will work" performance hacks that the gradle people built into their tool over the years. You get lots of complexity from layers of caching, daemons, half working offline modes, etc. They work a little bit but the multiple layers of hacks, outdated feature flags, etc. are annoying. - regular compatibility breaking changes that mean suddenly your build no longer works on a major version change. "we changed our mind, again, about how stuff is supposed to work" and please be fixing all your build files. The how bit is typically left as a hunt through bad documentation. - the maze of misdirection that is the documentation and the collective body of unhelpful stackoverflow posts and other online articles. Which thanks to regular compatibility breaking changes and the switch to kts tends to be groovy centric and hopelessly outdated. A lot of the "solutions" you find either don't work at all due to this or needs to be translated. Anything over two years old is probably wrong at this point. It's that bad. On a positive note, it does work once you get it dialed in. And I tend to not mess with my build files too much. If it looks like a shell script, I'm not even going to attempt doing it from gradle. I'll automate via github actions rather than gradle. Just easier. And while kts is a PITA to deal with in intellij (it freaks out regularly over phantom compile errors for no good reason whatsoever until you turn it off and on again), having auto completion helps. And being able to use regular kotlin to do stuff is also helpful. But doing simple things is still way too hard. Mostly I stick with gradle because it is the path of the least resistance. It's the thing that is supported by world + dog, probably the most likely thing to be documented, and others sort of expect it at this point. Everything else is more work to figure out and set up.

rickette 4y ago

For your typical run of the mill project just stick to Maven. The fact that it uses an XML file is not a real issue in any way shape or form.

shaftway 4y ago

I work on a large codebase that uses Gradle. We're occasionally held up as an example: "see? This corp uses Gradle for something this large, so it must be good." We have a regularly scheduled meeting with Gradle where we have in the past influenced their feature prioritization. We also have a former Gradle engineer on staff. Gradle is such garbage. I can't count the number of times our ex-Gradler has said "you're not going to like the answer..." Everything is action-at-a-distance and implicit. You can't answer basic questions like: - Why does this task exist? - Why does this task depend on this other task? - Why did this file get included or excluded? - How did I get 4 dependencies on 4 different versions of the same library? You can't answer this stuff because some random include file in some random place reached into a task that had already been created and modified it. And there's no way to find out where this happened. I don't understand why you would want a build system that has build tasks that are mutable. And yes, it would be nice if people wouldn't do action-at-a-distance, or would not do weird stuff to tasks after they've been created, but that's not really possible. We've actually gone through the trouble of writing a linter that makes sure that devs aren't doing anything too crazy in their .gradle files. But of course some files have to do crazy stuff, so there's an escape hatch, so everyone just uses that.

kaba0 4y ago
> that has build tasks that are mutable They are not mutable.. their configuration is. That’s like the whole point of gradle. Also, people should just learn to write plugins - that’s the proper way to add functionality.
- wiseowise 4y ago
  Don’t know why this is downvoted when it’s the truth. Build scripts are there to just configure stuff. Gradle is literally combination of tasks, plug-ins and artifacts.
  - Jolter 4y ago
    Then maybe Gradle should do what Maven does and disallow writing code in the configuration?

RamblingCTO 4y ago

While Gradle sucks and is complex af I really do like multi-module stuff. We can flesh out components that are intertwined, test them separately and things like that. So if you have a big backend that wouldn't make sense as microservices it really do helps. I haven't seen any other build tools that allow me to build multi-module stuff. Anyone?

piva00 4y ago
Maven? I've worked on quite a few large backend projects using multi-module in Maven, after it's setup it works: parent POM, submodules, dependency management on parent POM. It depends on what features specifically you are looking for though.
- RamblingCTO 4y ago
  I didn't know that. For me the biggest block is XML to be honest. I really dig kotlin in that regard.
  - piva00 4y ago
    XML is just verbose, after that it's pretty simple. It's all declarative, there's no code execution during build time that you have to keep in mind to build a mental model of what is actually executing, you read the XML, check the steps and configurations and can understand completely what's being executed. I like Kotlin, I don't like build tools that allow general computing during runtime where I will have to debug build code to understand what exactly has failed. Declarative tools are much better to reason about for most infrastructure tasks.

kaba0 4y ago

The author of this blog has been cutting the branch they’re sitting on, making the whole ordeal orders of magnitude more complex then it should be. With that said, Gradle’s official documentation is indeed bad and the necessary working model is hard to figure out, but that model is sound, and is necessary complexity for solving the general problem of dependency management. The problem is that there is a discrepancy between “download this and that dependency and run it” hobby projects, and the monstrosities that have to exist in large projects. Gradle is a general build tool, it could be used for multiple languages even. The well liked Cargo is of course much more user friendly, but it simply couldn’t be used as a general build tool, so it sheds a lot of weight there.

nitwit005 4y ago

Steps 2 to 10 are creating a plugin, and some later steps are a consequence of creating plugin subprojects, but I'm not sure why that was needed? From their description, the plugin just runs some things on the command line. Isn't this the most boring form of code generation?

tarkin2 4y ago

The RAM usage of the daemon, the fact there are two programming language you can write it in, and you’re often reading documentation based on the other language, with the newer language slowing down already slow, slow build times, the ever changing syntax, the abstractions, caching problems, the fact the build system is significantly more complex than 99% of anything it’ll ever build, makes writing bash scripts look appealing again.

kaba0 4y ago
What caching problem? Gradle really is correct in this regard (compared to Maven), it is likely some plugin that might cause troubles for you, which is not something Gradle can defend against. > the fact the build system is significantly more complex than 99% of anything it’ll ever build This is the real problem of Gradle — but is their any other tool for that 1%? Because it is definitely not any of the well-liked language specific ones like Cargo. Build tools are a hard problem.
- tarkin2 4y ago
  How many times have you just deleted the build folder to fix things? I use bash for my personal projects now. Thankfully I need none of the advanced features gradle provides/inflicts upon you.
  - kaba0 4y ago
    Never. And bash is an abomination, I would much rather use brainfuck :D

microflash 4y ago

I've tried Gradle again and again only to go back to Maven. Gradle is painfully slow on large (and even small) builds. It's backward compatibility story is non-existent. You can pick any two build files and chances are that they are completely different when compared. Groovy dialect has poor autocompletion support. Maven, on the other hand, has been extremely fast (with or without caching). I've been upgrading Maven for a long time and have yet to see an upgrade that breaks the build. I can pick any two POM files and chances are they are almost identical. XML, for all it's deficiencies, absolutely flies when it comes to autocompletion. My experience has been same from small projects to large multi-module projects.

kaba0 4y ago
Gradle is much faster than maven, as it supports parallel builds, has much smarter caching/evaluation strategies, etc. You just likely have tasks run at configuration time (you don’t use doFirst/doLast in custom tasks), or some other problematic build files.
- microflash 4y ago
  This reinforces my opinion about Gradle: there are too many footguns and papercuts. Every time I shot myself in foot using Gradle, some Gradle expert would chime in that I'm probably not using some (poorly documented) way of doing things that would have drastically improved my experience. This becomes even more problematic in large teams where we have a mix of experienced and novice engineers. Onboarding new people and maintaining the cognitive load about the build using Maven is several magnitudes faster and predictable than with Gradle.
- pjmlp 4y ago
  By requiring an always running background daemon to actually make it fast.
  - kaba0 4y ago
    No, gradle is fast in CICD settings as well where daemons are meaningless. It is fast because it has a proper graph model that only updates nodes that need to be updated, and can often do so in parallel.

amir734jj 4y ago

I'm not a Java guy, but Maven is much easier to learn but I have found some people in Java world religiously love Gradle. I don't know what is it with jvm language build tools ... Ehem sbt.

MrDresden 4y ago

I have been using Gradle for more then a decade and for the most part it works fine but occasionally there are situations where I have no clue what went wrong. Onboarding junior developers onto a big multi module projects that use Gradle can be really difficult. Understandably they are unable to grok the mental model (sometimes I even doubt if I do after all this time). One thing that has helped though has been switching entirely over to the Kotlin DSL.

smitty1e 4y ago

I got to the end of the article and realized that Gradle is "el drag" spelled backward. At that level of suffering, it sounds as though one has crafted a custom build tool for each non-trivial project.

naruhodo 4y ago

I love good rant and this one sent me into paroxysms of delight! About 9 out of 10 gradle build configurations that I have encountered fail to build something. That's surprising, and infuriating given that: * Gradle is based on a portability layer, the JVM. * Gradle competes against a portable and relatively reliable build system, Maven, and competes against make, which is non-portable due to its use of the system shell for arbitrary code. I would take Maven or make over Gradle any way of the week. I have one other major beef with Gradle: every single Gradle-based project I have encountered on GitHub includes the Gradle JAR file. The author wants me to download and execute arbitrary Java code without even the option of inspecting it! To hell with that! I had a breakthrough with Gradle recently: Gradle builds that fail on my Fedora laptop work just fine in an Ubuntu "toolbox" container. So much for portability! Like the author of the article, I have devoted several (not as many) hours to understanding Gradle. It is largely incomprehensible, when encountered in the wild.

miskin 4y ago
You do not need to use the gradle wrapper - you can use your own trusted version. Wrapper is there just for convenience. I understand your concerns, but it is not the only way and you are not forced to use it.
- naruhodo 4y ago
  I actually have tried to use the trusted version that comes with the Fedora packages. It was quite a while ago so I don't remember exactly why that didn't work, but I think it had to do with Fedora packaging an older version of Gradle than the build configuration required. So, nice thought. I guess I could work out what Ubuntu system the author used and set up a matching Ubuntu toolbox (container) with the right Gradle version. It's not really a win for Gradle if the developer's operating system has to be shipped with the build system.
- shaftway 4y ago
  Except that Gradle constantly releases new versions with breaking changes. You need to install your own trusted version for each version that you use, and know which one to use for each project.

cryptos 4y ago

There is more than Maven and Gradle. Maybe a new build tool callded "bld" could make life a bit easier: https://rife2.com/bld https://rife2.com/bld

piva00 4y ago
Why would I choose yet-another-build-tool if Maven works, is stable and backwards compatible? Even worse, why I would choose Java as my language to run a build? The only benefit is to avoid learning a tool that isn't Java, there's nothing else to it. For some Java build tool to actually gain traction it'd need to be better than Maven in every way, that's pretty hard to accomplish and I'd say that starting a tool that runs code already goes against the best practices for infrastructure code: convention-over-configuration, declarative.

bfrog 4y ago

Reason 101 why android studio and development is a horror show.

AtlasBarfed 4y ago

"modern, idiomatic, as-God-intended method of Gradle usage" Which changes literally every release, and half of my gradle tasks (already cobbled-together voodoo incantations) for shaded jars, dependency copying, integration tests, etc ... as in common tasks for build systems ... breaks. That said, building is HARD, and man is it HARD to pick up the nuances. Really there should be a massive standard feature set for build frameworks that every build framework has to document an example of. Ant was too XML-y, and too disorganized. Then came Maven (still XML-y) but way too rigid and limited. Then came gradle, which had potential, but largely is a failure. Gradle is well supported by IntelliJ. That's why it's the choice currently. I tried IntelliJ with Maven and it failed with some basic stuff, so it's gradle or ... nothing. The caveat, again, is that, like languages, there are two types of build systems: those you complain about (because you use them) and those that aren't used at all. I have not used bazel, pants, or any of the newer build frameworks. Make is both zealously pushed by neckbeards, but curiously used almost nowhere outside of C (a bad sign) and I've read really good "make sucks because" posts. It speaks to the general constant cycle of suck in software that building code, something that we've done in software for a half-century plus, has very little to show in the way of evolution and growth. But that's because there is nobody that has proper economic investment incentives. Even google probably underfunds Bazel. I almost wonder why google and those places don't have two groups / virtual companies that compete to be the build system based on project usage (I also wonder why large companies with a dozen datacenters don't have them compete against each other internally for customers / project funny money).

CmdrLoskene 4y ago

So Gradle is not a build tool, it's a tool for building build tools? That's wonderful, but that's not what I want. I am trying to solve problems in my particular domain. I want to spend my time solving those problems, not wrestling with my tool for building build tools. I just want a tool which knows how to build my things, given the dependencies I give it. I want a tool with clear and up-to-date documentation. I want a tool whose behavior I can reason over. Is that too much to ask? Apparently, for gradle, it's too much to ask.