18 ms·

The Problem with Gradle

269 points by wheresvic4 6y ago

koolba 6y ago
> 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.
- rwbhn 6y ago
  Came here to post the same quote. Matches my experience as well.
  - smitty1e 6y ago
    Then there is Jenkins. I looked at the jenkinsfile and said "I guess Java and Python had a tryst?" Eventually we'll get to the GitLab CI/CD, but the existing disaster supports the status quo, so it's not a priority.
    - noisy_boy 6y ago
      My experience with JenkinsFile has improved once we setup library functions for it to leverage on. Only downside is that you need to write them in Groovy but the payoff is that the JenkinsFile reduces to basically a function call or two per stage which makes it super clean + it makes JenkinsFiles more or less "standard" (because there is practically no project-specific stuff in it - the complexity is managed by the library functions). This approach has made fixing issues or enhancements so much more easier for us.
      - smitty1e 6y ago
        The "goodness" of Jenkins for my use-case is that the service can be a kind of "sudo" for capabilities we don't want to spread around. That said, learning Yet Another Language that only deals with a niche requirement is a total bore. If we can cook it down to executing some garden-variety bash in a special context, along with some spiffy pipeline visualization, that is enough.
        noisy_boy 6y ago
        At the end of the day, its just the shell executing the commands :) sure, you can always distil it down to a script (or a set of scripts) and nothing wrong with it either - as always, depends on the context.
- mrec 6y ago
  Yup. Gradle is by far the worst-designed technology I've encountered in ~30 years of programming. Using it not only made me not want to use Gradle, it made me not want to use Java.
  - TheRealSteel 6y ago
    I don't understand why Gradle breaks every second time I build my project, and I have to run Clean Project. If Clean Project is required to build the project, why isn't that part of the build process?
    - rwoerz 6y ago
      Same for Maven. Common reason: the mere presence of a "leftover after refactoring" file beneath target/ breaks the build because it is still included in the classpath.
      - eitland 6y ago
        FWIW: I've used Maven for years and I don't have these problems. When I am tasked with fixong other peoples config I usually move things to the correct location, delete the corresponding configuration qnd then everything works (better).
  - allenbrunson 6y ago
    hard agree. i took up flutter a couple of years ago, which means i am now saddled with (ugh) gradle for android builds. i am used to being able to intuit the underlying architecture of various tech things and fix them, which is utterly impossible as far as gradle goes. not only are the error messages unhelpful, they are usually confidently incorrect. they tell you the problem is likely thing X, which in fact has nothing to do with the problem. (to be fair, this seems to be coming from whatever stuff google has added to the android build process, rather than gradle itself.) these days, once gradle starts spitting errors, i know better than to read them. instead, i have to start thinking about when the build last worked, and what might have changed. if that path proves not to bear fruit, then it is time to trash that project completely and recreate it from scratch, which experience has taught me will take a lot less time than trying to “fix” the gradle build errors.
- bitcharmer 6y ago
  I have the same impression of gradle. If I have to learn another language (groovy) and a whole new platform infrastructure and APIs just to understand what a build does, it's definitely not worth the effort. Most of my peers have the same views. Fun fact: look up gradle in urban dictionary.
  - zmmmmm 6y ago
    This argument I don't really get. You're going to learn a "language" anyway - whatever build system you employ. It may or may not be Turing complete, but you're going to end up learning it once you get to any level of complexity in what you are doing. Why not have it be something with more general usefulness as well?
    - santoshalper 6y ago
      I have something with more general usefulness. It's called Java. I don't need a programming language to build my programming language.
- posedge 6y ago
  Yeah about that, do you have some insight on why the X background daemons are always 'incompatible' and gradle launches up new ones?
  - gddhn 6y ago
    Being new to Gradle, I used to run into this same issue. In one of the projects I use, I happened to find this comment, in github, which helped me fix the issue https://github.com/quarkusio/quarkus/issues/10454#issuecomment-653731422 https://github.com/quarkusio/quarkus/issues/10454#issuecomme... So increasing the default max heap size of the gradle build helped fix the issue https://github.com/quarkusio/quarkus/pull/10508/files https://github.com/quarkusio/quarkus/pull/10508/files.
    - benibela 6y ago
      And how could I make sure that the gradle I start on the command line and the gradle started by Android Studio use the same daemon?
PaulHoule 6y ago
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.
- Macha 6y ago
  I wonder if this is a reflection of enterprise processes. Writing a plugin in a previous employer meant creating a new repo, a new CI/CD pipeline, getting it pushed to artifactory, making sure people had the inhouse artifactory set up in their settings.xml, and all that had internal overhead. Also learning the maven plugin API. And nobody on your team would want to, so you'd be stuck answering every question about this feature forever more. Compared to gradle where the same tasks just require a few if statements in a scripting language.
  - dmitryminkovsky 6y ago
    This very much lines up with my experience. A long time ago I wrote a Maven plugin and decided to clean it up for open source. It got absolutely nowhere because after everything you describe—setting up a repo; learning the Maven API, which is one of those expansive APIs that has a lot of metaphoric semantic constructs—distributing it involved getting it into Maven Central by which point I had run out of time/mental bandwidth and never made it happen. Compare if I had been using Gradle at the time: I would have just coded it up in Groovy, a language I thoroughly enjoy, right there in setup. There are some things I don't like about Gradle, but there's a lot it has going for it, too. Personally, I like XML and enjoy Maven for situations where existing plugins are enough—which is 99% of the time—but that lack of flexibility can be constraining when existing plugins aren't enough.
    - lmm 6y ago
      I find that little hurdle actually improves the quality a lot. It means people don't write maven plugins for every single conceivable scenario; usually there will be at most one or two plugins for whatever you wanted to do, properly documented and maintained, whereas with gradle there will be four or five different plugins with no documentation each of which only covers half of the task. And forcing people to put logic in actual released plugins rather than ad-hoc one-liners in the middle of the build definition means you avoid ending up with a bunch of ad-hoc one-liners scattered throughout your build definition, which is much better for long-term maintenance.
kstenerud 6y ago
> 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.
- Cwizard 6y ago
  I agree. When I was a kid I had a camera that had an 'easy mode' in software. If you turned it on, the software would disable most advanced features and the UI would be something incredibly simple. This allowed me a complete novice to get started taking pictures. After some experience I turned the setting off and started to experiment with more advanced features without getting overwhelmed. I always wondered why not more products adopted this type of UX.
  - chr 6y ago
    Also nice how the built-in Iphone calculator app is plain and simple in portrait mode, and rivals a scientific calculator when rotated to landscape mode.
    - Tomte 6y ago
      The problem is that this is only discoverable by accident in specific circumstances. I almost never hold my phone in landscape.
      - 6y ago
pcw888 6y ago
I'm surpised to see such negative comments. I really enjoy using it - for a build tool that says a lot.
vbezhenar 6y ago
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.
- deleted 6y ago
  [deleted]
- sorokod 6y ago
  The person is Bruce Eckel, you may want to lookup his credentials.
- 0x445442 6y ago
  Or, if someone like Bruce Eckel has these observations it may be time to take a step back and listen.
- siva7 6y ago
  I think you might have issues comprehending what the Author is talking about or the history of maven/gradle.
strulovich 6y ago
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.
- anuragsoni 6y ago
  I concur. I worked on a java project at a previous job and Bazel was instrumental in getting fast deterministic builds. There were some growing pains as the bazel docs weren't great back then (this was before bazel reached 1.0), but once we got things to work it was nice to work with. We were able to leverage Bazel for our Angular application as well so it was nice to have everything building with one tool. > 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. I also agree with this. My current language of choice is OCaml and the most popular build tool is dune [1], which uses an s-expression based configuration language, and its nice to have a more restrictive DSL that avoids some pitfalls of using a full blown programming language for configuring builds. [1] https://dune.build/ https://dune.build/
freedomben 6y ago
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 https://archive.org/details/TICPP2ndEdVolOne [2] Volume 2 available for free on Archive.org: https://archive.org/details/TICPP2ndEdVolTwo https://archive.org/details/TICPP2ndEdVolTwo
- Tainnor 6y ago
  Interesting observation. I feel like I am like that - I hate doing anything that requires me to develop only a superficial understanding (e.g. messing around with Kubernetes configuration without understanding how it all works on a fundamental level). I also don't like systems that are hard to debug - I want to be able to make assumptions and test them, and that can sometimes be notoriously difficult with cloud-based infrastructure.
  - freedomben 6y ago
    Interesting you mention K8s, I had that same problem! It took me 6 months to get up to speed on K8s because I wanted to what everything meant, and those are all deep rabbit holes (like, try explaining the `apiVersion` in every object without going down a rabbit hole of how K8s works for example). Making that even worse there wasn't much out there to cover internals. The situation is much better now though. I guess that's part of price you pay to be an early adopter of the latest hotness.
motoboi 6y ago
One thing caught my attention on this site: where is the scrollbar (safari iPhone)?
- jlund-molfese 6y ago
  It's still there, it's just white instead of grey. Which works fine with the header, but disappears as you scroll.
pjmlp 6y ago
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.
- bassman9000 6y ago
  Gradle was the excuse ant writers/maintainers wanted not to migrate to Maven, because the latter forces you to be cleaner with your project organization.
- nsonha 6y ago
  Maybe this is a dumb question but I thought gradle kts was released a while ago. Why does everyone in this thread still complains about groovy? Could they not just use kotlin?
  - pjmlp 6y ago
    Because it still is work in progress.
  - wasyl 6y ago
    It's not an easy switch. Still most of the examples and articles are in Groovy. Until recently, IDE (IntelliJ) support for Gradle Kotlin DSL was abysmal (like analysing stuff on the main thread). Only recently it's getting more traction as the worst issues have been resolved.
- wasyl 6y ago
  > There is hardly any Android conference without build related performance improvement talks. fwiw I think the Android toolchain being slow doesn't help. On the same conferences someone will also speak about how the new Android Gradle Plugin is X% faster, so it's not all Gradle's fault :) That said there's plenty more Gradle can do (and is doing) to improve performance. The startup cost to configure all tasks is definitely high on my annoyances list
huodon 6y ago
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
jzoch 6y ago
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.
cmckn 6y ago
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.
grandinj 6y ago
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.
- pbourke 6y ago
  > Now “obviously” the answer is that we should have pegged the version of gradle required to use the script My first step with either gradle or maven is to install the wrapper generator, which has this effect. After adding the wrapper you invoke it via ./gradlew or ./mvnw in the project directory. The version of gradle or maven is then pinned until manually updated. It’s not perfect - especially in terms of IDE support - but it’s crucial for keeping your CLI builds consistent across team members and in automation. gradle wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.html https://docs.gradle.org/current/userguide/gradle_wrapper.htm... maven wrapper: https://github.com/takari/maven-wrapper https://github.com/takari/maven-wrapper
irateswami 6y ago
I'm so glad I don't have to deal with Java and it's ecosystem anymore.
- pjmlp 6y ago
  Luckily it is possible to be happy in Java ecosystem without touching anything Gradle related, unless one needs to deal with Android. That is my path to happiness, Netbeans | Eclipse + Maven.
  - mateuszf 6y ago
    Intellij + Maven here, also very happy with it
  - irateswami 6y ago
    Maven is worse than Gradle.
moonbug 6y ago
Gradle's purpose is to make cmake seem palatable.
larusso 6y ago
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.
wbkang 6y ago
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.
draw_down 6y ago
> 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”.
ohgodplsno 6y ago
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.
DrBazza 6y ago
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.
cataphract 6y ago
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.
- emsy 6y ago
  Having used Gradle, I disagree. Even if you know Groovy, declarations in Gradle are executed in a certain order and you don't really know what a closure does or what it's side effects are. Sometimes you have to read the source code because the documentation is insufficient. Gradle is not a simple tool and the documentation (last time I was using it) isn't helping.
  - cataphract 6y ago
    I agree that order of execution is sometimes problematic in Groovy and you have to use evaluationDependsOn() or afterEvaluate {}. I don't think the DSLs are per se particularly problematic; they generally just set some properties of the task (when they're more complex and yet the abstraction leaks, then they do more harm than do). But yes, the documentation is awful, and is IMO the biggest problem with Gradle.
- acaloiar 6y ago
emsy 6y ago
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.
- cataphract 6y ago
  You very much can debug Gradle. It's just like any other Java/Groovy application. You set a breakpoint in the build file or some Gradle source file and you attach a debugger. In this respect, it's probably more debug-friendly than, say Makefiles where all you can do is add some print statements or go through megabytes of debug output.
  - wasyl 6y ago
    Adding to that, in IntelliJ it's as simple as running the task from the 'run Gradle task' window (not sure how it's called) with Shift pressed. All the breakpoints in the build scripts will now work. If you also use wrapper with sources (`-all` instead of `-bin` suffix in the `gradle/wrapper/gradle-wrapper.properties`) you can step into the entire Gradle source code as well
  - santoshalper 6y ago
    In over 30 years of programming, I have never had to debug a makefile. I think I would just retire if I ever had to.
    - emsy 6y ago
      Sometimes builds are complex. You have several deployment paths, platforms, modules, features, signing and what not. Then the build is akin to a small program. That’s still reasonable. The problem is that all build tools that allow this make it more complex than simply writing a small script that does exactly what you need. Add to that that some dependemcies use a different build tool that you use. Adding a cmake dependency to a make project makes everything even more complex.
ncmncm 6y ago
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.
- huodon 6y ago
  I agree with you very much. Since gradle supported kotlin script(typed), I seem to have a little understanding of it. I have used it for a long time. Besides the treat the sunk cost, Maven makes people less willing to use it than gradle.
franzwong 6y ago
About point 6, even you don't execute task "a", gradle will still execute the configuration part of it.
lazulicurio 6y ago
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.
zestyping 6y ago
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.
- p2detar 6y ago
  > 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. Gradle has build cache since version 3.5 [0]. You probably mean the configuration phase for which caching was introduced in version 6.6. [1] Gradle has been consistently improving the last couple of years. I’m quite happy with its speed since the v6.5 upgrade. 0 - https://docs.gradle.org/current/userguide/build_cache.html https://docs.gradle.org/current/userguide/build_cache.html 1 - https://docs.gradle.org/6.6/release-notes.html https://docs.gradle.org/6.6/release-notes.html
  - oblio 6y ago
    Its architecture is so broken that they had to introduce 3 concepts to speed Gradle up: - daemon - build cache - config cache for a build tool! And it only took them more a full decade to implement them (the config cache is still experimental). And even all those things only take it from "molasses slow" to "bearable".
coding123 6y ago
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.
nucatus 6y ago
all you need to know about gradle is that there are two phases: configuration and execution. Everything else are details :)
- twic 6y ago
  It took me months of working with Gradle before this clicked, but once it did, everything seemed far simpler.
stunt 6y ago
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.
- 0x445442 6y ago
  Yeah, I've never used the combination professionally but Any wity Ivy always struck me as the happy zone. Although, over time, Maven's lack of explicit flow control has bothered me less and less.
deathcap 6y ago
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 https://github.com/GlowstoneMC/Glowstone -> http://github.com/GlowstonePlusPlus/GlowstonePlusPlus http://github.com/GlowstonePlusPlus/GlowstonePlusPlus
therealdrag0 6y ago
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...
- misja111 6y ago
  +1. SBT is a lot like Gradle but worse. Funny anecdote: SBT originally stood for 'simple build tool'. At some point this was changed to 'Scala build tool' and I can fully understand why ..
fctorial 6y ago
build.sh ftw.
jayd16 6y ago
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.
- gozzoo 6y ago
  Because it fixes some of the problems of Maven, which was the defacto standard in the Java world, and is quite horrible. Gradle is to Maven what svn was to cvs.
  - pjmlp 6y ago
    What problems? The only one is XML allergy.
    - jayd16 6y ago
      I've seen people claim Gradle is language agnostic and Maven isn't. Not sure I agree but its what I'm told...
      - jdmichal 6y ago
        Maven defaults to Java, but I'm pretty sure there's compilation plugins for all the JVM languages.
    - blktiger 6y ago
      Speed - a gradle build computes hashes of all the build steps so it knows when to skip things that don’t need to be run. Spring converted their builds to gradle and were able to cut their builds from an hour to 10 minutes (full-ci bulds). https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle https://spring.io/blog/2020/06/08/migrating-spring-boot-s-bu...
habosa 6y ago
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.
zmmmmm 6y ago
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 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.
- piva00 6y ago
  Very concise description of my own experience when trying to learn Gradle from its docs, frustrating wheel spinning and utter confusing to understand from a high level to a detailed view.
- oblio 6y ago
  Random guess: they never user test new docs (especially with newbies). Docs are written by Gradle devs with years of intimate knowledge of the tool and just published somewhere in their dev cycle.
  - cratermoon 6y ago
    And with that, they document the things Gradle does, not how to accomplish basic tasks using Gradle.
- Noumenon72 6y ago
  I love how you and others have articulated exactly how I felt. I'm not alone! There are not many tools or languages that have left me with such a memory of unlearnability. I powered through, I made things happen, but I feel less powerful in Gradle than anything else I spent so much time learning.
The_rationalist 6y ago
Really? https://melix.github.io/blog/2021/01/the-problem-with-gradle.html https://melix.github.io/blog/2021/01/the-problem-with-gradle...
pabl0rg 6y ago
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).
cdaringe 6y ago
Strong agreement with the author's points. https://cdaringe.github.io/rad/#why-not-my-favorite-build-tool 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
alisausaaaa 6y ago
Wanna have hot-lovin' conversations? You’re on the right way! - https://adultlove.life https://adultlove.life
npstr 6y ago
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.
ashtonkem 6y ago
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.
hiram112 6y ago
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.
avmich 6y ago
I've found similar problems with all by-convention platforms, like Django and Rails.
coffexx 6y ago
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.
tn1 6y ago
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 https://github.com/skylot/jadx
kimi 6y ago
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.
ma01zm 6y ago
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.
joshum97 6y ago
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!
devnull255 6y ago
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.

269 points by wheresvic4 6y ago

> 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.

rwbhn 6y ago
Came here to post the same quote. Matches my experience as well.
- smitty1e 6y ago
  Then there is Jenkins. I looked at the jenkinsfile and said "I guess Java and Python had a tryst?" Eventually we'll get to the GitLab CI/CD, but the existing disaster supports the status quo, so it's not a priority.
  - noisy_boy 6y ago
    My experience with JenkinsFile has improved once we setup library functions for it to leverage on. Only downside is that you need to write them in Groovy but the payoff is that the JenkinsFile reduces to basically a function call or two per stage which makes it super clean + it makes JenkinsFiles more or less "standard" (because there is practically no project-specific stuff in it - the complexity is managed by the library functions). This approach has made fixing issues or enhancements so much more easier for us.
    - smitty1e 6y ago
      The "goodness" of Jenkins for my use-case is that the service can be a kind of "sudo" for capabilities we don't want to spread around. That said, learning Yet Another Language that only deals with a niche requirement is a total bore. If we can cook it down to executing some garden-variety bash in a special context, along with some spiffy pipeline visualization, that is enough.
      - noisy_boy 6y ago
        At the end of the day, its just the shell executing the commands :) sure, you can always distil it down to a script (or a set of scripts) and nothing wrong with it either - as always, depends on the context.
mrec 6y ago
Yup. Gradle is by far the worst-designed technology I've encountered in ~30 years of programming. Using it not only made me not want to use Gradle, it made me not want to use Java.
- TheRealSteel 6y ago
  I don't understand why Gradle breaks every second time I build my project, and I have to run Clean Project. If Clean Project is required to build the project, why isn't that part of the build process?
  - rwoerz 6y ago
    Same for Maven. Common reason: the mere presence of a "leftover after refactoring" file beneath target/ breaks the build because it is still included in the classpath.
    - eitland 6y ago
      FWIW: I've used Maven for years and I don't have these problems. When I am tasked with fixong other peoples config I usually move things to the correct location, delete the corresponding configuration qnd then everything works (better).
- allenbrunson 6y ago
  hard agree. i took up flutter a couple of years ago, which means i am now saddled with (ugh) gradle for android builds. i am used to being able to intuit the underlying architecture of various tech things and fix them, which is utterly impossible as far as gradle goes. not only are the error messages unhelpful, they are usually confidently incorrect. they tell you the problem is likely thing X, which in fact has nothing to do with the problem. (to be fair, this seems to be coming from whatever stuff google has added to the android build process, rather than gradle itself.) these days, once gradle starts spitting errors, i know better than to read them. instead, i have to start thinking about when the build last worked, and what might have changed. if that path proves not to bear fruit, then it is time to trash that project completely and recreate it from scratch, which experience has taught me will take a lot less time than trying to “fix” the gradle build errors.
bitcharmer 6y ago
I have the same impression of gradle. If I have to learn another language (groovy) and a whole new platform infrastructure and APIs just to understand what a build does, it's definitely not worth the effort. Most of my peers have the same views. Fun fact: look up gradle in urban dictionary.
- zmmmmm 6y ago
  This argument I don't really get. You're going to learn a "language" anyway - whatever build system you employ. It may or may not be Turing complete, but you're going to end up learning it once you get to any level of complexity in what you are doing. Why not have it be something with more general usefulness as well?
  - santoshalper 6y ago
    I have something with more general usefulness. It's called Java. I don't need a programming language to build my programming language.
posedge 6y ago
Yeah about that, do you have some insight on why the X background daemons are always 'incompatible' and gradle launches up new ones?
- gddhn 6y ago
  Being new to Gradle, I used to run into this same issue. In one of the projects I use, I happened to find this comment, in github, which helped me fix the issue https://github.com/quarkusio/quarkus/issues/10454#issuecomment-653731422 https://github.com/quarkusio/quarkus/issues/10454#issuecomme... So increasing the default max heap size of the gradle build helped fix the issue https://github.com/quarkusio/quarkus/pull/10508/files https://github.com/quarkusio/quarkus/pull/10508/files.
  - benibela 6y ago
    And how could I make sure that the gradle I start on the command line and the gradle started by Android Studio use the same daemon?

PaulHoule 6y ago

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.

Macha 6y ago
I wonder if this is a reflection of enterprise processes. Writing a plugin in a previous employer meant creating a new repo, a new CI/CD pipeline, getting it pushed to artifactory, making sure people had the inhouse artifactory set up in their settings.xml, and all that had internal overhead. Also learning the maven plugin API. And nobody on your team would want to, so you'd be stuck answering every question about this feature forever more. Compared to gradle where the same tasks just require a few if statements in a scripting language.
- dmitryminkovsky 6y ago
  This very much lines up with my experience. A long time ago I wrote a Maven plugin and decided to clean it up for open source. It got absolutely nowhere because after everything you describe—setting up a repo; learning the Maven API, which is one of those expansive APIs that has a lot of metaphoric semantic constructs—distributing it involved getting it into Maven Central by which point I had run out of time/mental bandwidth and never made it happen. Compare if I had been using Gradle at the time: I would have just coded it up in Groovy, a language I thoroughly enjoy, right there in setup. There are some things I don't like about Gradle, but there's a lot it has going for it, too. Personally, I like XML and enjoy Maven for situations where existing plugins are enough—which is 99% of the time—but that lack of flexibility can be constraining when existing plugins aren't enough.
  - lmm 6y ago
    I find that little hurdle actually improves the quality a lot. It means people don't write maven plugins for every single conceivable scenario; usually there will be at most one or two plugins for whatever you wanted to do, properly documented and maintained, whereas with gradle there will be four or five different plugins with no documentation each of which only covers half of the task. And forcing people to put logic in actual released plugins rather than ad-hoc one-liners in the middle of the build definition means you avoid ending up with a bunch of ad-hoc one-liners scattered throughout your build definition, which is much better for long-term maintenance.

kstenerud 6y ago

> 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.

Cwizard 6y ago
I agree. When I was a kid I had a camera that had an 'easy mode' in software. If you turned it on, the software would disable most advanced features and the UI would be something incredibly simple. This allowed me a complete novice to get started taking pictures. After some experience I turned the setting off and started to experiment with more advanced features without getting overwhelmed. I always wondered why not more products adopted this type of UX.
- chr 6y ago
  Also nice how the built-in Iphone calculator app is plain and simple in portrait mode, and rivals a scientific calculator when rotated to landscape mode.
  - Tomte 6y ago
    The problem is that this is only discoverable by accident in specific circumstances. I almost never hold my phone in landscape.
    - 6y ago

pcw888 6y ago

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

vbezhenar 6y ago

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.

deleted 6y ago
[deleted]
sorokod 6y ago
The person is Bruce Eckel, you may want to lookup his credentials.
0x445442 6y ago
Or, if someone like Bruce Eckel has these observations it may be time to take a step back and listen.
siva7 6y ago
I think you might have issues comprehending what the Author is talking about or the history of maven/gradle.

strulovich 6y ago

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.

anuragsoni 6y ago
I concur. I worked on a java project at a previous job and Bazel was instrumental in getting fast deterministic builds. There were some growing pains as the bazel docs weren't great back then (this was before bazel reached 1.0), but once we got things to work it was nice to work with. We were able to leverage Bazel for our Angular application as well so it was nice to have everything building with one tool. > 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. I also agree with this. My current language of choice is OCaml and the most popular build tool is dune [1], which uses an s-expression based configuration language, and its nice to have a more restrictive DSL that avoids some pitfalls of using a full blown programming language for configuring builds. [1] https://dune.build/ https://dune.build/

freedomben 6y ago

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 https://archive.org/details/TICPP2ndEdVolOne [2] Volume 2 available for free on Archive.org: https://archive.org/details/TICPP2ndEdVolTwo https://archive.org/details/TICPP2ndEdVolTwo

Tainnor 6y ago
Interesting observation. I feel like I am like that - I hate doing anything that requires me to develop only a superficial understanding (e.g. messing around with Kubernetes configuration without understanding how it all works on a fundamental level). I also don't like systems that are hard to debug - I want to be able to make assumptions and test them, and that can sometimes be notoriously difficult with cloud-based infrastructure.
- freedomben 6y ago
  Interesting you mention K8s, I had that same problem! It took me 6 months to get up to speed on K8s because I wanted to what everything meant, and those are all deep rabbit holes (like, try explaining the `apiVersion` in every object without going down a rabbit hole of how K8s works for example). Making that even worse there wasn't much out there to cover internals. The situation is much better now though. I guess that's part of price you pay to be an early adopter of the latest hotness.

motoboi 6y ago

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

jlund-molfese 6y ago
It's still there, it's just white instead of grey. Which works fine with the header, but disappears as you scroll.

pjmlp 6y ago

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.

bassman9000 6y ago
Gradle was the excuse ant writers/maintainers wanted not to migrate to Maven, because the latter forces you to be cleaner with your project organization.
nsonha 6y ago
Maybe this is a dumb question but I thought gradle kts was released a while ago. Why does everyone in this thread still complains about groovy? Could they not just use kotlin?
- pjmlp 6y ago
  Because it still is work in progress.
- wasyl 6y ago
  It's not an easy switch. Still most of the examples and articles are in Groovy. Until recently, IDE (IntelliJ) support for Gradle Kotlin DSL was abysmal (like analysing stuff on the main thread). Only recently it's getting more traction as the worst issues have been resolved.
wasyl 6y ago
> There is hardly any Android conference without build related performance improvement talks. fwiw I think the Android toolchain being slow doesn't help. On the same conferences someone will also speak about how the new Android Gradle Plugin is X% faster, so it's not all Gradle's fault :) That said there's plenty more Gradle can do (and is doing) to improve performance. The startup cost to configure all tasks is definitely high on my annoyances list

huodon 6y ago

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

jzoch 6y ago

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.

cmckn 6y ago

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.

grandinj 6y ago

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.

pbourke 6y ago
> Now “obviously” the answer is that we should have pegged the version of gradle required to use the script My first step with either gradle or maven is to install the wrapper generator, which has this effect. After adding the wrapper you invoke it via ./gradlew or ./mvnw in the project directory. The version of gradle or maven is then pinned until manually updated. It’s not perfect - especially in terms of IDE support - but it’s crucial for keeping your CLI builds consistent across team members and in automation. gradle wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.html https://docs.gradle.org/current/userguide/gradle_wrapper.htm... maven wrapper: https://github.com/takari/maven-wrapper https://github.com/takari/maven-wrapper

irateswami 6y ago

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

pjmlp 6y ago
Luckily it is possible to be happy in Java ecosystem without touching anything Gradle related, unless one needs to deal with Android. That is my path to happiness, Netbeans | Eclipse + Maven.
- mateuszf 6y ago
  Intellij + Maven here, also very happy with it
- irateswami 6y ago
  Maven is worse than Gradle.

moonbug 6y ago

Gradle's purpose is to make cmake seem palatable.

larusso 6y ago

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.

wbkang 6y ago

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.

draw_down 6y ago

> 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”.

ohgodplsno 6y ago

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.

DrBazza 6y ago

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.

cataphract 6y ago

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.

emsy 6y ago
Having used Gradle, I disagree. Even if you know Groovy, declarations in Gradle are executed in a certain order and you don't really know what a closure does or what it's side effects are. Sometimes you have to read the source code because the documentation is insufficient. Gradle is not a simple tool and the documentation (last time I was using it) isn't helping.
- cataphract 6y ago
  I agree that order of execution is sometimes problematic in Groovy and you have to use evaluationDependsOn() or afterEvaluate {}. I don't think the DSLs are per se particularly problematic; they generally just set some properties of the task (when they're more complex and yet the abstraction leaks, then they do more harm than do). But yes, the documentation is awful, and is IMO the biggest problem with Gradle.
acaloiar 6y ago

emsy 6y ago

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.

cataphract 6y ago
You very much can debug Gradle. It's just like any other Java/Groovy application. You set a breakpoint in the build file or some Gradle source file and you attach a debugger. In this respect, it's probably more debug-friendly than, say Makefiles where all you can do is add some print statements or go through megabytes of debug output.
- wasyl 6y ago
  Adding to that, in IntelliJ it's as simple as running the task from the 'run Gradle task' window (not sure how it's called) with Shift pressed. All the breakpoints in the build scripts will now work. If you also use wrapper with sources (`-all` instead of `-bin` suffix in the `gradle/wrapper/gradle-wrapper.properties`) you can step into the entire Gradle source code as well
- santoshalper 6y ago
  In over 30 years of programming, I have never had to debug a makefile. I think I would just retire if I ever had to.
  - emsy 6y ago
    Sometimes builds are complex. You have several deployment paths, platforms, modules, features, signing and what not. Then the build is akin to a small program. That’s still reasonable. The problem is that all build tools that allow this make it more complex than simply writing a small script that does exactly what you need. Add to that that some dependemcies use a different build tool that you use. Adding a cmake dependency to a make project makes everything even more complex.

ncmncm 6y ago

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.

huodon 6y ago
I agree with you very much. Since gradle supported kotlin script(typed), I seem to have a little understanding of it. I have used it for a long time. Besides the treat the sunk cost, Maven makes people less willing to use it than gradle.

franzwong 6y ago

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

lazulicurio 6y ago

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.

zestyping 6y ago

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.

p2detar 6y ago
> 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. Gradle has build cache since version 3.5 [0]. You probably mean the configuration phase for which caching was introduced in version 6.6. [1] Gradle has been consistently improving the last couple of years. I’m quite happy with its speed since the v6.5 upgrade. 0 - https://docs.gradle.org/current/userguide/build_cache.html https://docs.gradle.org/current/userguide/build_cache.html 1 - https://docs.gradle.org/6.6/release-notes.html https://docs.gradle.org/6.6/release-notes.html
- oblio 6y ago
  Its architecture is so broken that they had to introduce 3 concepts to speed Gradle up: - daemon - build cache - config cache for a build tool! And it only took them more a full decade to implement them (the config cache is still experimental). And even all those things only take it from "molasses slow" to "bearable".

coding123 6y ago

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.

nucatus 6y ago

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

twic 6y ago
It took me months of working with Gradle before this clicked, but once it did, everything seemed far simpler.

stunt 6y ago

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.

0x445442 6y ago
Yeah, I've never used the combination professionally but Any wity Ivy always struck me as the happy zone. Although, over time, Maven's lack of explicit flow control has bothered me less and less.

deathcap 6y ago

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 https://github.com/GlowstoneMC/Glowstone -> http://github.com/GlowstonePlusPlus/GlowstonePlusPlus http://github.com/GlowstonePlusPlus/GlowstonePlusPlus

therealdrag0 6y ago

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...

misja111 6y ago
+1. SBT is a lot like Gradle but worse. Funny anecdote: SBT originally stood for 'simple build tool'. At some point this was changed to 'Scala build tool' and I can fully understand why ..

fctorial 6y ago

build.sh ftw.

jayd16 6y ago

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.

gozzoo 6y ago
Because it fixes some of the problems of Maven, which was the defacto standard in the Java world, and is quite horrible. Gradle is to Maven what svn was to cvs.
- pjmlp 6y ago
  What problems? The only one is XML allergy.
  - jayd16 6y ago
    I've seen people claim Gradle is language agnostic and Maven isn't. Not sure I agree but its what I'm told...
    - jdmichal 6y ago
      Maven defaults to Java, but I'm pretty sure there's compilation plugins for all the JVM languages.
  - blktiger 6y ago
    Speed - a gradle build computes hashes of all the build steps so it knows when to skip things that don’t need to be run. Spring converted their builds to gradle and were able to cut their builds from an hour to 10 minutes (full-ci bulds). https://spring.io/blog/2020/06/08/migrating-spring-boot-s-build-to-gradle https://spring.io/blog/2020/06/08/migrating-spring-boot-s-bu...

habosa 6y ago

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.

zmmmmm 6y ago

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 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.

piva00 6y ago
Very concise description of my own experience when trying to learn Gradle from its docs, frustrating wheel spinning and utter confusing to understand from a high level to a detailed view.
oblio 6y ago
Random guess: they never user test new docs (especially with newbies). Docs are written by Gradle devs with years of intimate knowledge of the tool and just published somewhere in their dev cycle.
- cratermoon 6y ago
  And with that, they document the things Gradle does, not how to accomplish basic tasks using Gradle.
Noumenon72 6y ago
I love how you and others have articulated exactly how I felt. I'm not alone! There are not many tools or languages that have left me with such a memory of unlearnability. I powered through, I made things happen, but I feel less powerful in Gradle than anything else I spent so much time learning.

The_rationalist 6y ago

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

pabl0rg 6y ago

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).

cdaringe 6y ago

Strong agreement with the author's points. https://cdaringe.github.io/rad/#why-not-my-favorite-build-tool 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

alisausaaaa 6y ago

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

npstr 6y ago

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.

ashtonkem 6y ago

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.

hiram112 6y ago

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.

avmich 6y ago

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

coffexx 6y ago

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.

tn1 6y ago

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 https://github.com/skylot/jadx

kimi 6y ago

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.

ma01zm 6y ago

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.

joshum97 6y ago

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!

devnull255 6y ago

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.