32 ms·

Gradle 7.0

102 points by gher-shyu3i 6y ago

bambam24 6y ago
This project is still alive? Why??
dvfjsdhgfv 6y ago
Sometimes I feel they should stop the development of all new features and concentrate exclusively on performance improvement (which, fortunately, is not neglected in this release).
- okr 6y ago
  Yup. I also stopped upgrading. Too much work.
  - josteink 6y ago
    Granted it was many years ago, but my only experience with Gradle was through Android Studio. Basically, as I remember it, every time Android studio updated Gradle, my project broke. No exceptions, even though this was a stock Android Studio project. Seemingly things are still that terrible? If so, why do you people keep using it? What problems does Gradle solve which other build-systems don’t solve better
    - ohgodplsno 6y ago
      Gradle is sufficiently implanted into the Android ecosytem that moving away is hard. When you have a project with 80+ modules, buildSrc contents, gradle plugins, well, moving to Bazel isn't exactly a one day job. Add to that that many things add Gradle plugins that might be necessary for your workflow, and well, you're in a bad state.
      - thu2111 6y ago
        Unfortunately that's also now the case for the Kotlin ecosystem. I attempted to use Maven recently for a simple Kotlin project and recently switched to Gradle. This is NOT because I like Gradle. Oh god if there is any project and company that badly needs some competition it is Gradle Inc. But the Maven/Kotlin ecosystem is bit-rotting. Maven itself is hardly maintained. It's now common to find libraries or tools that only really work properly with Gradle and de-prioritise Maven related issues. Gradle is winning by default, even though it's arguably a step sideways from Maven.
- avmich 6y ago
  Even before that I'd prefer them improving the documentation :) . It's pretty senseless to have a system with even a good performance which can't be used because of a cryptic behavior. I'm yet to see a good explanation for how Gradle should be used. Is knowing Groovy a prerequisite?
  - scaladev 6y ago
    These days you can write build scripts in Kotlin. It provides proper type checking and better auto-completion.
  - vbezhenar 6y ago
    I don't know which documentation do you miss. Gradle has pretty extensive documentation, stackoverflow has all kinds of answers and other websites have plenty of tutorials. I don't know Groovy and I was able to write complicated enough multi-project builds with some custom build steps by copy-pasting snippets from the Internet and applying some common sense. I guess, Groovy knowledge is required if you need to write build plugins.
    - vesinisa 6y ago
      No, Gradle's documentation is really terrible. There is just no easy path to learn it - you will with time and pain learn a bit of the interface, but deep down it remains mostly unfanthonable, unnecessarily complex and filled with strange quirks. Bruce Eckel had pretty much the same experience as myself: https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ https://www.bruceeckel.com/2021/01/02/the-problem-with-gradl... Everone "learns" Gradle by copy-pasting snippets from the Internet and then having to fix them when they break. And what little I have learned of Gradle over the years was certainly not thanks to their documentation, but other people explaining the concepts in blog posts and tutorials. The Gradle documentation always assumes that you will want to learn the whole build system from ground up. There is no simple documentation for people who see Gradle just as a tool secondary to their actual product that is just built with it. It is in many ways similar to git. You can't really learn git unless you learn it from the ground up. But git is actually really simple when compared to Gradle, and most people do learn git eventually through using it. But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation. Oh, and at least git's interface and structure has remained mostly static ever since the original concept by Linus in 2005. Same can not be said of Gradle - I feel like the developer interface is like a sand castle that is washed away every second release, and I assume the internals keep shifting as well. What a nightmare to work with.
- vbezhenar 6y ago
  What features do you think they should not ship? Apple Silicon support obviously is necessary. Support for Java 16 is necessary. Centralized dependency management is long-awaited feature. Type safe project accessors are very nice to have. I would say that they should not stop the development of all new features, but rather they should spend more time designing those features, so they don't have to change them in the future (making old variants obsolete and broken in the end). But modern software development is agile, move fast and break things and all that.
- popotamonga 6y ago
  I never understood why my android app with only 300 classes and 20 libs takes more than 1m to build on my custom 5k$ computer. In comparison i have a c# project 3x bigger and only takes a few seconds to fully rebuild. Maybe its just how android is and nothing to do with graddle but still...
  - ohgodplsno 6y ago
    A lot of it is Android, yes. A regular build run will involve kotlin annotation processing, kotlin compilation, java annotation processing, java compilation, AAPT2, dexing, sometimes d8/r8 if you're in release mode, as well as a whole host of various processes that you can forget about until it hits you with a build error that will have you puzzled for a few hours. EDIT: right, Jetifier too, because that's always a lot of fun.
  - kaba0 6y ago
    From experience, non-android java project will build roughly in the same time as comparable amount of C# code, with both maven and gradle. It is definitely android that increases it.
bruce343434 6y ago
Cool ad
ohgodplsno 6y ago
Sweet can't wait to repeat the gradle update cycle! * "Gradle update? Performance babyyyy" * "Oh, <obscure feature that needed to be hacked around> no longer works. It's okay, let's fix it. * "Oh, no, it's actually not backwards compatible and I have to figure out what kind of awkward cast as an <AndroidPluginInterface> I have to do because gradle still doesn't expose proper types in half their kotlin DSL" * "Right, entire build cache gone. It's okay, 15 minutes." * "right! Now let's get an incremental change and see the perfo... Right, kapt still isn't incremental"
- tootoon 6y ago
  Heh, and the java people complain about web being unstable.
- The_rationalist 6y ago
  Right, kapt still isn't incremental" Why isn't your KAPT incremental? Kapt supports incremental annotation processing that is enabled by default. Currently, annotation processing can be incremental only if all annotation processors being used are incremental.
  - ohgodplsno 6y ago
    androidx.room is only incremental starting from 2.3.0-beta3. No stable release yet.
    - EvilEy3 6y ago
      I don't see how issue of one plugin is a problem of a tool.
sheikheddy 6y ago
Does anyone have a good resource for learning a systematic way to do dependency management for large codebases? Seems like every time it comes up in gradle or maven I have to trial-and-error my way out of resolution hell.
- bitcharmer 6y ago
  Just use Maven. Could you point out what exactly in Maven makes it hard to use for you?
  - jpgvm 6y ago
    Maven makes doing things off the beaten path very hard. This can be good as most Maven builds won't surprise anyone but if you often find yourself doing such things (mixed language projects, custom code generation steps, etc) then Maven will always be harder to use and you will have to spend more time writing plugins vs Gradle. Maven is great when all you want to do is build a simple Java project and publish it, when you step outside of that it becomes much more painful.
    - andrewaylett 6y ago
      Maven is great so long as there's a plugin to do what you need to do. If there isn't, it's quite possible that writing one will be simpler than trying to coax Maven into doing something unorthodox. For example, here's an old plugin I put together to allow easy publishing of a third-party artefact to a repository that didn't have a web interface for such things: https://github.com/andrewaylett/prepackaged https://github.com/andrewaylett/prepackaged It's old enough that the infrastructure I set up around it has bit-rotted -- I've just pushed a clone to GitHub to share here :). I'd hope using modern language features would make it easier still.
      - jpgvm 6y ago
        Yeah this remains Gradles main advantage. You can author inline code to do interesting things or even full plugins by taking advantage of the buildSrc functionality.
crossroadsguy 6y ago
Gradle had a lot to do with my attempts to move away from Android development. Well, not that other tools are shiny beacons of goodness, but still Gradle takes the cake effortlessly.
- agilob 6y ago
  I feel you. Gradle is the reason why I stopped updating my opensource android projects and killed them. I once got updates to translation files, wanted to update gradlew as it was ~2 years old. Failed with updates for +16 hours spent on it. Multiple gradle functions replaced or removed, dozen of incompatible changes, broken syntax, incompatible gradle plugins I used for C compilation... I simply gave up, archived the repo, stopped accepting translations and moved away from Android. Simply too much effort was wasted trying to keep dependencies up to date every year or so. Just look at some of these breaking changes reported for 7.0: [#16652] - Trouble using centralized dependency versions in buildSrc plugins and buildscript classpath [#16620] - FileNotFoundException in TestKit tests: lib-android/build/20210320_1519030999411730848.compiler.options [#16541] - Impossible to run modular program with 7.0-milestone-2. Working with 6.8 [#16532] - Build failure when including a plugin build in settings & applying a settings plugin [#16163] - Using included builds for local settings plugins don't seem to work [#16028] - Change in behaviour when resolving custom project dependencies I without going into details, two of these would affect the project I talked above... These breaking changes should be enough to block release of 7.0 before 100s of developers are hit by these time-wasting issues.
  - charrondev 6y ago
    Also seems like a horrible idea to use a custom DSL for the configuration. Just another curveball to throw at you. XML, yaml, toml, json, something else standard and well known would have been nice.
    - jorams 6y ago
      I don't think this criticism makes much sense. XML, yaml, toml or json would replace the current choice of Groovy or Kotlin, but the actual configuration would be just as much of a DSL.
kioleanu 6y ago
I have a project that runs specifically on Gradle 3.5. No more, no less. I am not making the mistake of touching that part of the project again. PS: thank you Gradle maintainers for offering a download of all versions at a click's distance
felipelemos 6y ago
I wish maven would work with something other than XML.
- carrja99 6y ago
  When I was last doing Java development ten years ago they had a groovy dsl, did they discontinue that?
  - krzyk 6y ago
    DSL is what is wrong with Gradle.
- kohlerm 6y ago
  I wish maven would have a proper way to resolve version conflicts and incremental builds
- mdaniel 6y ago
  It seems merely adding a file to the .mvn directory will do as you wish: https://github.com/takari/polyglot-maven#usage https://github.com/takari/polyglot-maven#usage I have avoided that road because it's one more thing that is a snowflake in the very area where I don't want to blazing trails. But I have personally tried their approach before and can confirm it does work as advertised. I can't recall if IJ lost its mind over pulling a stunt like that, but arguably if it did, then filing a YouTrack is an appropriate next step
Traubenfuchs 6y ago
Gradle considered harmful. https://phauer.com/2018/moving-back-from-gradle-to-maven/#tldr https://phauer.com/2018/moving-back-from-gradle-to-maven/#tl...
- bitcharmer 6y ago
  The move from Gradle back to Maven I've seen on all Java projects employing Gradle so far (and I worked on many such projects).
  - watt 6y ago
    Maven have been really great preserving backward compatibility. And Gradle have been really careless, breaking things left and right. Why couldn't they spend more effort to preserve compatibility for a little longer? In effect we are unable to move versions forward on Gradle projects, and legacy projects are stuck on legacy Gradle.
edoceo 6y ago
On one hand we've all these devs who love the new tooling. And I feel like some geezer when I complain about vendor-driven churn. And here's a great example, and many complaints and stories. And I'm sad the lesson wont be learnt this time either
kohlerm 6y ago
Version catalogs Sound Like an interesting feature to ne.
ur-whale 6y ago
Grade is a shiny beacon exemplifying the mindset of the entire Java ecosystem.
jpgvm 6y ago
Lots of Gradle hate in here. To provide a counter-point I love Gradle. Yes it's complex, yes the learning curve is basically a cliff (you either understand Gradle or you don't) and yes it can be slow. But on the positive side: I use the Kotlin DSL and the majority of my new projects are Kotlin also. As a result I now have a single language in use and no need to switch contexts. Type safe, null safe DSL for build configuration that also happens to be the same language I want to write my project in anyway? Yes please. It's basically Ruby Rake but better in this regard. Potentially contentious point but I love being able to extend Gradle on a per-project basis with buildSrc plugins. This allows me to handle more complex tasks in a way that abstracts that complexity from the members of my team that don't necessarily have the same level of time invested in Gradle. I like that it downloads itself via wrapper script. My projects only have one local dependency, a recent JDK. The build system downloads itself, then downloads all the project dependencies. This makes it easy for non-JVM members of my company to check the project out, make a small change and build the project without learning 5 other tools. cough Javascript cough. I like that it's versioned per project when using the wrapper. I don't need to worry about some sort of runtime or package manager switcher like you would in Python/Ruby/Javascript land. Don't get me wrong, Gradle is a long lived project with lots of skeletons in the closet but overall I think it's a very pragmatic tool for small projects all the way up to mid-sized monorepos. There does come a point when you will want to look at Buck or Bazel but most teams will never reach this point.
- tn1 6y ago
  > I like that it downloads itself via wrapper script. While I also use and enjoy Gradle, this is IMO its biggest weakness. We've all seen the recent supply-chain attacks, and ~everyone's infra is at risk here. There isn't even anything similar to Javascript's subresource integrity! I'm sure that the people hosting Gradle are very cautious, but it only takes one slip-up...
  - jpgvm 6y ago
    They could add a signature check to the wrapper script to resolve this concern.
tekkk 6y ago
Configuring Gradle is my vision of programming torture. It's a mandatory side step, unrelated to your main task. A mere chore, without any great programming paradigms to at least teach you something interesting. Just pure violence of leaky abstractions that can only be solved by sheer trial and error.
- zmmmmm 6y ago
  I feel you. I think the only way out is to put aside time to actually start from scratch and actually learn it properly. A really big issue with Gradle is the pretense you can work with it easily without learning it. You absolutely have to understand its fundamentals (which are not obvious, btw) to work with it and not hate it I think.
- jerrygoyal 6y ago
  working outside of modern js ecosystem (react, node etc) would be my nightmare. There are tons of resources, best DX, continuous new features which actually make web performance better, and a vibrant community around it. I wish these platform apps die one day and everyone would build and serve on web technologies. This is my personal opinion.
  - EvilEy3 6y ago
    Calm down, Satan.
justin_oaks 6y ago
My experience with gradle (5+ years ago) was that there was too much "magic" going on. It would do things without me specifying that it should, like convention-over-configuration taken to its limits. Has that changed over the years? Has it gotten better or worse?
- jpgvm 6y ago
  Better in some regards, worse in others. The Kotlin DSL I think made things a lot less magic at the cost of being a bit more leaky with abstractions.
- Rapzid 6y ago
  I believe for years they have been trying to improve the experience for use cases that aren't an opinionated, old school, Java publishing pipeline. Both through the API flexibility and documentation that explains more about the concepts of what's going on behind the scenes(how the Java plugin configures a bunch of tasks by default, what they are, and etc). The "new" publishing system is still a thorn in my side. It doesn't play well with existing Gradle paradigms(like configurations) and seems to force most people into giving up on it when they have some variation of the use case "Publish a dynamic list of files(aka unknown list) produced by task/subproject and not the stock Java tasks." There's a trail of frustration going back nearly a decade; unanswered questions, answers that don't address the use cases, and a general lack of acknowledgement that the "new" system isn't getting the job done for people in a friendly, flexible way.
adonese 6y ago
I'm neither a java dev nor Android dev, but our android guy left the team and I had to maintain our android app. Gradle is really a huge burden for me to get the app up and running and for someone who was only lightly interested into doing small changes one the fly, gradle was totally upsetting. I think it kinda fits into tools that suit much large scale projects, while they fall short to address small scale projects.
- pjmlp 6y ago
  Android is the only reason Gradle is still relevant, had it not been for Google pushing it, maybe some key manager just loves it, it would be almost irrelevant on the Java world.
  - EvilEy3 6y ago
    > Android is the only reason Gradle is still relevant And this small thing called Spring, maybe you heard about it? But yeah, other than that it is almost irrelevant, if you count Netflix, Adyen and thousands of other companies irrelevant.
    - pjmlp 6y ago
      Nah, that is just Pivotal following Java fashion as usually, Spring has been always usable with Maven. Netflix and Adyen are indeed irrelevant in the context of Java consulting.
      - fcurts 6y ago
        Fortune 100 here. Gradle is the dominant Java build tool (thousands of projects). I haven't seen a single project move back to Maven. Some projects are moving to Bazel, but that's not a walk in the park either.
        pjmlp 6y ago
        This Fortune 100 on this side doesn't do Gradle other than for Android, I am yet to see a JEE, SAP, LifeRay or AEM project using Gradle in production.
miked85 6y ago
I never understood why one would want to use Gradle over Maven. Gradle seems like a very complicated way to avoid using XML as configuration and essentially end up with Ant.
- ptx 6y ago
  One big advantage is the Gradle daemon, which (in return for consuming all available memory) saves you from having to spin up the JVM every time you build and can be substantially faster. It seems someone has recently created something similar for Maven: https://github.com/mvndaemon/mvnd https://github.com/mvndaemon/mvnd
  - cratermoon 6y ago
    > saves you from having to spin up the JVM every time you build Too bad most CI/CD pipelines are effectively stateless, spinning up a new vm, docker image, or whatever for every run. Gradle's cold startup time is awful now that they've pushed more and more into the deamon, make it a major bottleneck in build times.
    - kaba0 6y ago
      Does it really matter how long CI build takes (in terms of it being a few percent slower/faster)? And incremental builds when one develops does boost performance significantly.
      - lmm 6y ago
        For local development you're using your IDE to build, no? (At least if your IDE understands your build definition, which is always with Maven and sometimes with Gradle). So CI is the only case where the speed of the command-line build matters.
        kaba0 6y ago
        And what do you think your IDE calls? Also, NOT building with the project’s build tool is a giant red flag of doing something bad. That way you are testing different things then what will run after deploy.
avolcano 6y ago
Interesting discussion here. I've been very happy with Gradle for my first major JVM project, a small Kotlin API with a simple build configuration (https://github.com/thomasboyt/jam-buds/blob/master/rhiannon/build.gradle.kts https://github.com/thomasboyt/jam-buds/blob/master/rhiannon/...). I suppose I'm not surprised to see more complaints from folks who have worked with it on much longer-lived and _much_ more complex projects. I've been thinking of taking a peek into Java, which I've never really written[1]. Is the general thinking that, for something like a Spring Boot application, it's much better to just start with Maven? I'll admit I am, aesthetically, displeased with the mountains of XML config I've seen in some tutorial articles, but I imagine it's a lot simpler to maintain over time than any DSL would be. [1] slightly off-topic, but if anyone's curious why: I haven't been very impressed by any of the "Kotlin-first" JVM libraries I've seen (like ktor or exposed), I think coroutines are neat but much more suitable for main-thread-focused situations like Android apps than something more easily threaded like web servers (and with Project Loom hopefully upcoming in the next couple years this might be a moot point soon), and I don't like the JetBrains tooling lock-in (e.g there's no well-supported language server for Kotlin, unlike what Red Hat's been building for Java)
- lmm 6y ago
  > I've been thinking of taking a peek into Java, which I've never really written[1]. Is the general thinking that, for something like a Spring Boot application, it's much better to just start with Maven? I'll admit I am, aesthetically, displeased with the mountains of XML config I've seen in some tutorial articles, but I imagine it's a lot simpler to maintain over time than any DSL would be. If you're using Spring Boot then you might as well also use Gradle, since they're the same kind of write-only incomprehensible system (I wouldn't be surprised if they were made by the same people). But yes if you want to be able to maintain your build definition for the long term and actually understand how it works rather than cargo-cult copy/pasting snippets and praying then Maven is a much better tool.
- fiddlerwoaroof 6y ago
  At my last job, one of the onboarding tasks was writing a simple Java servlet that met a specification: the only two rules were (1) 100% unit test coverage of all the code you wrote and (2) you should be able to explain every line of every file in the repository. After I finished that and from my later experience with Maven, I really don’t find maven all that scary: writing all the XML isn’t my favorite thing to do, but it’s surprisingly straightforward to get a minimal pom.xml that works for 80% of the projects you work on.
la_fayette 6y ago
Gradle is a new problem to solve an existing problem and thus making it an even bigger problem. We tried to use gradle for an existing large spring application, after days of groovy and illogic we went back to maven... At least Android studio takes care of most of the gradle stuff. I will take a look at the Kotlin DSL, maybe it was just groovy.
elric 6y ago
I quite like gradle for small projects. But as soon as the project reaches an arbitrary threshold of complexity, gradle goes from boon to bust. The venerable ant is so much simpler to use in complex environments. Or maven, which -- unlike gradle -- has a pretty stable plugin API...
tarkin2 6y ago
First there was Ant. Ant was bad. Then there was Maven. Maven bad less bad. But still bad. Then there was Gradle. Gradle was even less bad. But still bad. Show me the build tool - I'll show you the bad. My main gripe is that it changed so quickly. All my notes quickly became useless. And it was slow. Gradle daemon promised to help. And it did help. (And became even more of a resource hog) But it was still bad. Show me the build tool - I'll show you the bad.
- miked85 6y ago
  Ant wasn't bad, it was a big step up from using Make for Java builds. Maven wasn't bad either. It tried to enforce convention over configuration, while also introducing a native dependency management mechanism. Gradle was/is bad and serves no real purpose.
- tootoon 6y ago
  > Show me the build tool - I'll show you the bad. build.sh
einpoklum 6y ago
Suppose I'm a C++ developer on Unix-like systems. I know about Make and CMake, and maybe even a bit of meson and ninja. w.r.t. package management - maybe Conan; my OS distro; and getting stuff directly from the web. What are the pro's of me switching to Gradle? What would Gradle replace for me?
- pjmlp 6y ago
  For C++ development don't even bother, unless you plan to target Android, and even there you are better just sticking with cmake and ndk-build as much as you can.
kabdib 6y ago
Gradle is one of those rare tools that makes me wish I was driving a tractor.
beders 6y ago
Tools have a very hard time understanding arbitrary gradle scripts. Since your config language is Turing-complete, you can easily subvert any kind of assistance from tools like Intellij IDEA. Parsing XML on the other hand and adding some semantic to well-defined tags or even plugins: That's much simpler and more robust. (Yes, you can do scripting inside some maven plugins, but if you do that, I'll come over and sit on your keyboard until you can convince me that there was no other way) Avoid gradle like the plague.
cutler 6y ago
Gradle, please die!
pabs3 6y ago
I wonder if this improves the bootstrappability of Gradle. https://bootstrappable.org/projects/java-tools.html https://bootstrappable.org/projects/java-tools.html
skinkestek 6y ago
So far from what I've seen Gradle has been an exercise in frustration from my perspective: a few people "get it", the rest copy and adapt leaving a mess worthy of an evolution theory for code. Then again, I don't want to be like certain others: the above is just observations from my very limited point of view. Maybe in a year I love Gradle the same way I love Java today after initially finding it almost insane. After all there are some seriously smart people using Gradle and thinking I'm smarter than all of them would be some serious hubris from me.
- oblio 6y ago
  > a few people "get it", the rest copy and adapt leaving a mess worthy of an evolution theory for code. Even better, geological layers :-))
Shadonototro 6y ago
my OS boot faster than gradle, it says a lot about why people "hate" working with gradle projects

102 points by gher-shyu3i 6y ago

This project is still alive? Why??

Sometimes I feel they should stop the development of all new features and concentrate exclusively on performance improvement (which, fortunately, is not neglected in this release).

okr 6y ago
Yup. I also stopped upgrading. Too much work.
- josteink 6y ago
  Granted it was many years ago, but my only experience with Gradle was through Android Studio. Basically, as I remember it, every time Android studio updated Gradle, my project broke. No exceptions, even though this was a stock Android Studio project. Seemingly things are still that terrible? If so, why do you people keep using it? What problems does Gradle solve which other build-systems don’t solve better
  - ohgodplsno 6y ago
    Gradle is sufficiently implanted into the Android ecosytem that moving away is hard. When you have a project with 80+ modules, buildSrc contents, gradle plugins, well, moving to Bazel isn't exactly a one day job. Add to that that many things add Gradle plugins that might be necessary for your workflow, and well, you're in a bad state.
    - thu2111 6y ago
      Unfortunately that's also now the case for the Kotlin ecosystem. I attempted to use Maven recently for a simple Kotlin project and recently switched to Gradle. This is NOT because I like Gradle. Oh god if there is any project and company that badly needs some competition it is Gradle Inc. But the Maven/Kotlin ecosystem is bit-rotting. Maven itself is hardly maintained. It's now common to find libraries or tools that only really work properly with Gradle and de-prioritise Maven related issues. Gradle is winning by default, even though it's arguably a step sideways from Maven.
avmich 6y ago
Even before that I'd prefer them improving the documentation :) . It's pretty senseless to have a system with even a good performance which can't be used because of a cryptic behavior. I'm yet to see a good explanation for how Gradle should be used. Is knowing Groovy a prerequisite?
- scaladev 6y ago
  These days you can write build scripts in Kotlin. It provides proper type checking and better auto-completion.
- vbezhenar 6y ago
  I don't know which documentation do you miss. Gradle has pretty extensive documentation, stackoverflow has all kinds of answers and other websites have plenty of tutorials. I don't know Groovy and I was able to write complicated enough multi-project builds with some custom build steps by copy-pasting snippets from the Internet and applying some common sense. I guess, Groovy knowledge is required if you need to write build plugins.
  - vesinisa 6y ago
    No, Gradle's documentation is really terrible. There is just no easy path to learn it - you will with time and pain learn a bit of the interface, but deep down it remains mostly unfanthonable, unnecessarily complex and filled with strange quirks. Bruce Eckel had pretty much the same experience as myself: https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ https://www.bruceeckel.com/2021/01/02/the-problem-with-gradl... Everone "learns" Gradle by copy-pasting snippets from the Internet and then having to fix them when they break. And what little I have learned of Gradle over the years was certainly not thanks to their documentation, but other people explaining the concepts in blog posts and tutorials. The Gradle documentation always assumes that you will want to learn the whole build system from ground up. There is no simple documentation for people who see Gradle just as a tool secondary to their actual product that is just built with it. It is in many ways similar to git. You can't really learn git unless you learn it from the ground up. But git is actually really simple when compared to Gradle, and most people do learn git eventually through using it. But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation. Oh, and at least git's interface and structure has remained mostly static ever since the original concept by Linus in 2005. Same can not be said of Gradle - I feel like the developer interface is like a sand castle that is washed away every second release, and I assume the internals keep shifting as well. What a nightmare to work with.
vbezhenar 6y ago
What features do you think they should not ship? Apple Silicon support obviously is necessary. Support for Java 16 is necessary. Centralized dependency management is long-awaited feature. Type safe project accessors are very nice to have. I would say that they should not stop the development of all new features, but rather they should spend more time designing those features, so they don't have to change them in the future (making old variants obsolete and broken in the end). But modern software development is agile, move fast and break things and all that.
popotamonga 6y ago
I never understood why my android app with only 300 classes and 20 libs takes more than 1m to build on my custom 5k$ computer. In comparison i have a c# project 3x bigger and only takes a few seconds to fully rebuild. Maybe its just how android is and nothing to do with graddle but still...
- ohgodplsno 6y ago
  A lot of it is Android, yes. A regular build run will involve kotlin annotation processing, kotlin compilation, java annotation processing, java compilation, AAPT2, dexing, sometimes d8/r8 if you're in release mode, as well as a whole host of various processes that you can forget about until it hits you with a build error that will have you puzzled for a few hours. EDIT: right, Jetifier too, because that's always a lot of fun.
- kaba0 6y ago
  From experience, non-android java project will build roughly in the same time as comparable amount of C# code, with both maven and gradle. It is definitely android that increases it.

bruce343434 6y ago

Cool ad

ohgodplsno 6y ago

Sweet can't wait to repeat the gradle update cycle! * "Gradle update? Performance babyyyy" * "Oh, <obscure feature that needed to be hacked around> no longer works. It's okay, let's fix it. * "Oh, no, it's actually not backwards compatible and I have to figure out what kind of awkward cast as an <AndroidPluginInterface> I have to do because gradle still doesn't expose proper types in half their kotlin DSL" * "Right, entire build cache gone. It's okay, 15 minutes." * "right! Now let's get an incremental change and see the perfo... Right, kapt still isn't incremental"

tootoon 6y ago
Heh, and the java people complain about web being unstable.
The_rationalist 6y ago
Right, kapt still isn't incremental" Why isn't your KAPT incremental? Kapt supports incremental annotation processing that is enabled by default. Currently, annotation processing can be incremental only if all annotation processors being used are incremental.
- ohgodplsno 6y ago
  androidx.room is only incremental starting from 2.3.0-beta3. No stable release yet.
  - EvilEy3 6y ago
    I don't see how issue of one plugin is a problem of a tool.

sheikheddy 6y ago

Does anyone have a good resource for learning a systematic way to do dependency management for large codebases? Seems like every time it comes up in gradle or maven I have to trial-and-error my way out of resolution hell.

bitcharmer 6y ago
Just use Maven. Could you point out what exactly in Maven makes it hard to use for you?
- jpgvm 6y ago
  Maven makes doing things off the beaten path very hard. This can be good as most Maven builds won't surprise anyone but if you often find yourself doing such things (mixed language projects, custom code generation steps, etc) then Maven will always be harder to use and you will have to spend more time writing plugins vs Gradle. Maven is great when all you want to do is build a simple Java project and publish it, when you step outside of that it becomes much more painful.
  - andrewaylett 6y ago
    Maven is great so long as there's a plugin to do what you need to do. If there isn't, it's quite possible that writing one will be simpler than trying to coax Maven into doing something unorthodox. For example, here's an old plugin I put together to allow easy publishing of a third-party artefact to a repository that didn't have a web interface for such things: https://github.com/andrewaylett/prepackaged https://github.com/andrewaylett/prepackaged It's old enough that the infrastructure I set up around it has bit-rotted -- I've just pushed a clone to GitHub to share here :). I'd hope using modern language features would make it easier still.
    - jpgvm 6y ago
      Yeah this remains Gradles main advantage. You can author inline code to do interesting things or even full plugins by taking advantage of the buildSrc functionality.

crossroadsguy 6y ago

Gradle had a lot to do with my attempts to move away from Android development. Well, not that other tools are shiny beacons of goodness, but still Gradle takes the cake effortlessly.

agilob 6y ago
I feel you. Gradle is the reason why I stopped updating my opensource android projects and killed them. I once got updates to translation files, wanted to update gradlew as it was ~2 years old. Failed with updates for +16 hours spent on it. Multiple gradle functions replaced or removed, dozen of incompatible changes, broken syntax, incompatible gradle plugins I used for C compilation... I simply gave up, archived the repo, stopped accepting translations and moved away from Android. Simply too much effort was wasted trying to keep dependencies up to date every year or so. Just look at some of these breaking changes reported for 7.0: [#16652] - Trouble using centralized dependency versions in buildSrc plugins and buildscript classpath [#16620] - FileNotFoundException in TestKit tests: lib-android/build/20210320_1519030999411730848.compiler.options [#16541] - Impossible to run modular program with 7.0-milestone-2. Working with 6.8 [#16532] - Build failure when including a plugin build in settings & applying a settings plugin [#16163] - Using included builds for local settings plugins don't seem to work [#16028] - Change in behaviour when resolving custom project dependencies I without going into details, two of these would affect the project I talked above... These breaking changes should be enough to block release of 7.0 before 100s of developers are hit by these time-wasting issues.
- charrondev 6y ago
  Also seems like a horrible idea to use a custom DSL for the configuration. Just another curveball to throw at you. XML, yaml, toml, json, something else standard and well known would have been nice.
  - jorams 6y ago
    I don't think this criticism makes much sense. XML, yaml, toml or json would replace the current choice of Groovy or Kotlin, but the actual configuration would be just as much of a DSL.

kioleanu 6y ago

I have a project that runs specifically on Gradle 3.5. No more, no less. I am not making the mistake of touching that part of the project again. PS: thank you Gradle maintainers for offering a download of all versions at a click's distance

felipelemos 6y ago

I wish maven would work with something other than XML.

carrja99 6y ago
When I was last doing Java development ten years ago they had a groovy dsl, did they discontinue that?
- krzyk 6y ago
  DSL is what is wrong with Gradle.
kohlerm 6y ago
I wish maven would have a proper way to resolve version conflicts and incremental builds
mdaniel 6y ago
It seems merely adding a file to the .mvn directory will do as you wish: https://github.com/takari/polyglot-maven#usage https://github.com/takari/polyglot-maven#usage I have avoided that road because it's one more thing that is a snowflake in the very area where I don't want to blazing trails. But I have personally tried their approach before and can confirm it does work as advertised. I can't recall if IJ lost its mind over pulling a stunt like that, but arguably if it did, then filing a YouTrack is an appropriate next step

Traubenfuchs 6y ago

Gradle considered harmful. https://phauer.com/2018/moving-back-from-gradle-to-maven/#tldr https://phauer.com/2018/moving-back-from-gradle-to-maven/#tl...

bitcharmer 6y ago
The move from Gradle back to Maven I've seen on all Java projects employing Gradle so far (and I worked on many such projects).
- watt 6y ago
  Maven have been really great preserving backward compatibility. And Gradle have been really careless, breaking things left and right. Why couldn't they spend more effort to preserve compatibility for a little longer? In effect we are unable to move versions forward on Gradle projects, and legacy projects are stuck on legacy Gradle.

edoceo 6y ago

On one hand we've all these devs who love the new tooling. And I feel like some geezer when I complain about vendor-driven churn. And here's a great example, and many complaints and stories. And I'm sad the lesson wont be learnt this time either

kohlerm 6y ago

Version catalogs Sound Like an interesting feature to ne.

ur-whale 6y ago

Grade is a shiny beacon exemplifying the mindset of the entire Java ecosystem.

jpgvm 6y ago

Lots of Gradle hate in here. To provide a counter-point I love Gradle. Yes it's complex, yes the learning curve is basically a cliff (you either understand Gradle or you don't) and yes it can be slow. But on the positive side: I use the Kotlin DSL and the majority of my new projects are Kotlin also. As a result I now have a single language in use and no need to switch contexts. Type safe, null safe DSL for build configuration that also happens to be the same language I want to write my project in anyway? Yes please. It's basically Ruby Rake but better in this regard. Potentially contentious point but I love being able to extend Gradle on a per-project basis with buildSrc plugins. This allows me to handle more complex tasks in a way that abstracts that complexity from the members of my team that don't necessarily have the same level of time invested in Gradle. I like that it downloads itself via wrapper script. My projects only have one local dependency, a recent JDK. The build system downloads itself, then downloads all the project dependencies. This makes it easy for non-JVM members of my company to check the project out, make a small change and build the project without learning 5 other tools. cough Javascript cough. I like that it's versioned per project when using the wrapper. I don't need to worry about some sort of runtime or package manager switcher like you would in Python/Ruby/Javascript land. Don't get me wrong, Gradle is a long lived project with lots of skeletons in the closet but overall I think it's a very pragmatic tool for small projects all the way up to mid-sized monorepos. There does come a point when you will want to look at Buck or Bazel but most teams will never reach this point.

tn1 6y ago
> I like that it downloads itself via wrapper script. While I also use and enjoy Gradle, this is IMO its biggest weakness. We've all seen the recent supply-chain attacks, and ~everyone's infra is at risk here. There isn't even anything similar to Javascript's subresource integrity! I'm sure that the people hosting Gradle are very cautious, but it only takes one slip-up...
- jpgvm 6y ago
  They could add a signature check to the wrapper script to resolve this concern.

tekkk 6y ago

Configuring Gradle is my vision of programming torture. It's a mandatory side step, unrelated to your main task. A mere chore, without any great programming paradigms to at least teach you something interesting. Just pure violence of leaky abstractions that can only be solved by sheer trial and error.

zmmmmm 6y ago
I feel you. I think the only way out is to put aside time to actually start from scratch and actually learn it properly. A really big issue with Gradle is the pretense you can work with it easily without learning it. You absolutely have to understand its fundamentals (which are not obvious, btw) to work with it and not hate it I think.
jerrygoyal 6y ago
working outside of modern js ecosystem (react, node etc) would be my nightmare. There are tons of resources, best DX, continuous new features which actually make web performance better, and a vibrant community around it. I wish these platform apps die one day and everyone would build and serve on web technologies. This is my personal opinion.
- EvilEy3 6y ago
  Calm down, Satan.

justin_oaks 6y ago

My experience with gradle (5+ years ago) was that there was too much "magic" going on. It would do things without me specifying that it should, like convention-over-configuration taken to its limits. Has that changed over the years? Has it gotten better or worse?

jpgvm 6y ago
Better in some regards, worse in others. The Kotlin DSL I think made things a lot less magic at the cost of being a bit more leaky with abstractions.
Rapzid 6y ago
I believe for years they have been trying to improve the experience for use cases that aren't an opinionated, old school, Java publishing pipeline. Both through the API flexibility and documentation that explains more about the concepts of what's going on behind the scenes(how the Java plugin configures a bunch of tasks by default, what they are, and etc). The "new" publishing system is still a thorn in my side. It doesn't play well with existing Gradle paradigms(like configurations) and seems to force most people into giving up on it when they have some variation of the use case "Publish a dynamic list of files(aka unknown list) produced by task/subproject and not the stock Java tasks." There's a trail of frustration going back nearly a decade; unanswered questions, answers that don't address the use cases, and a general lack of acknowledgement that the "new" system isn't getting the job done for people in a friendly, flexible way.

adonese 6y ago

I'm neither a java dev nor Android dev, but our android guy left the team and I had to maintain our android app. Gradle is really a huge burden for me to get the app up and running and for someone who was only lightly interested into doing small changes one the fly, gradle was totally upsetting. I think it kinda fits into tools that suit much large scale projects, while they fall short to address small scale projects.

pjmlp 6y ago
Android is the only reason Gradle is still relevant, had it not been for Google pushing it, maybe some key manager just loves it, it would be almost irrelevant on the Java world.
- EvilEy3 6y ago
  > Android is the only reason Gradle is still relevant And this small thing called Spring, maybe you heard about it? But yeah, other than that it is almost irrelevant, if you count Netflix, Adyen and thousands of other companies irrelevant.
  - pjmlp 6y ago
    Nah, that is just Pivotal following Java fashion as usually, Spring has been always usable with Maven. Netflix and Adyen are indeed irrelevant in the context of Java consulting.
    - fcurts 6y ago
      Fortune 100 here. Gradle is the dominant Java build tool (thousands of projects). I haven't seen a single project move back to Maven. Some projects are moving to Bazel, but that's not a walk in the park either.
      - pjmlp 6y ago
        This Fortune 100 on this side doesn't do Gradle other than for Android, I am yet to see a JEE, SAP, LifeRay or AEM project using Gradle in production.

miked85 6y ago

I never understood why one would want to use Gradle over Maven. Gradle seems like a very complicated way to avoid using XML as configuration and essentially end up with Ant.

ptx 6y ago
One big advantage is the Gradle daemon, which (in return for consuming all available memory) saves you from having to spin up the JVM every time you build and can be substantially faster. It seems someone has recently created something similar for Maven: https://github.com/mvndaemon/mvnd https://github.com/mvndaemon/mvnd
- cratermoon 6y ago
  > saves you from having to spin up the JVM every time you build Too bad most CI/CD pipelines are effectively stateless, spinning up a new vm, docker image, or whatever for every run. Gradle's cold startup time is awful now that they've pushed more and more into the deamon, make it a major bottleneck in build times.
  - kaba0 6y ago
    Does it really matter how long CI build takes (in terms of it being a few percent slower/faster)? And incremental builds when one develops does boost performance significantly.
    - lmm 6y ago
      For local development you're using your IDE to build, no? (At least if your IDE understands your build definition, which is always with Maven and sometimes with Gradle). So CI is the only case where the speed of the command-line build matters.
      - kaba0 6y ago
        And what do you think your IDE calls? Also, NOT building with the project’s build tool is a giant red flag of doing something bad. That way you are testing different things then what will run after deploy.

avolcano 6y ago

Interesting discussion here. I've been very happy with Gradle for my first major JVM project, a small Kotlin API with a simple build configuration (https://github.com/thomasboyt/jam-buds/blob/master/rhiannon/build.gradle.kts https://github.com/thomasboyt/jam-buds/blob/master/rhiannon/...). I suppose I'm not surprised to see more complaints from folks who have worked with it on much longer-lived and _much_ more complex projects. I've been thinking of taking a peek into Java, which I've never really written[1]. Is the general thinking that, for something like a Spring Boot application, it's much better to just start with Maven? I'll admit I am, aesthetically, displeased with the mountains of XML config I've seen in some tutorial articles, but I imagine it's a lot simpler to maintain over time than any DSL would be. [1] slightly off-topic, but if anyone's curious why: I haven't been very impressed by any of the "Kotlin-first" JVM libraries I've seen (like ktor or exposed), I think coroutines are neat but much more suitable for main-thread-focused situations like Android apps than something more easily threaded like web servers (and with Project Loom hopefully upcoming in the next couple years this might be a moot point soon), and I don't like the JetBrains tooling lock-in (e.g there's no well-supported language server for Kotlin, unlike what Red Hat's been building for Java)

lmm 6y ago
> I've been thinking of taking a peek into Java, which I've never really written[1]. Is the general thinking that, for something like a Spring Boot application, it's much better to just start with Maven? I'll admit I am, aesthetically, displeased with the mountains of XML config I've seen in some tutorial articles, but I imagine it's a lot simpler to maintain over time than any DSL would be. If you're using Spring Boot then you might as well also use Gradle, since they're the same kind of write-only incomprehensible system (I wouldn't be surprised if they were made by the same people). But yes if you want to be able to maintain your build definition for the long term and actually understand how it works rather than cargo-cult copy/pasting snippets and praying then Maven is a much better tool.
fiddlerwoaroof 6y ago
At my last job, one of the onboarding tasks was writing a simple Java servlet that met a specification: the only two rules were (1) 100% unit test coverage of all the code you wrote and (2) you should be able to explain every line of every file in the repository. After I finished that and from my later experience with Maven, I really don’t find maven all that scary: writing all the XML isn’t my favorite thing to do, but it’s surprisingly straightforward to get a minimal pom.xml that works for 80% of the projects you work on.

la_fayette 6y ago

Gradle is a new problem to solve an existing problem and thus making it an even bigger problem. We tried to use gradle for an existing large spring application, after days of groovy and illogic we went back to maven... At least Android studio takes care of most of the gradle stuff. I will take a look at the Kotlin DSL, maybe it was just groovy.

elric 6y ago

I quite like gradle for small projects. But as soon as the project reaches an arbitrary threshold of complexity, gradle goes from boon to bust. The venerable ant is so much simpler to use in complex environments. Or maven, which -- unlike gradle -- has a pretty stable plugin API...

tarkin2 6y ago

First there was Ant. Ant was bad. Then there was Maven. Maven bad less bad. But still bad. Then there was Gradle. Gradle was even less bad. But still bad. Show me the build tool - I'll show you the bad. My main gripe is that it changed so quickly. All my notes quickly became useless. And it was slow. Gradle daemon promised to help. And it did help. (And became even more of a resource hog) But it was still bad. Show me the build tool - I'll show you the bad.

miked85 6y ago
Ant wasn't bad, it was a big step up from using Make for Java builds. Maven wasn't bad either. It tried to enforce convention over configuration, while also introducing a native dependency management mechanism. Gradle was/is bad and serves no real purpose.
tootoon 6y ago
> Show me the build tool - I'll show you the bad. build.sh

einpoklum 6y ago

Suppose I'm a C++ developer on Unix-like systems. I know about Make and CMake, and maybe even a bit of meson and ninja. w.r.t. package management - maybe Conan; my OS distro; and getting stuff directly from the web. What are the pro's of me switching to Gradle? What would Gradle replace for me?

pjmlp 6y ago
For C++ development don't even bother, unless you plan to target Android, and even there you are better just sticking with cmake and ndk-build as much as you can.

kabdib 6y ago

Gradle is one of those rare tools that makes me wish I was driving a tractor.

beders 6y ago

Tools have a very hard time understanding arbitrary gradle scripts. Since your config language is Turing-complete, you can easily subvert any kind of assistance from tools like Intellij IDEA. Parsing XML on the other hand and adding some semantic to well-defined tags or even plugins: That's much simpler and more robust. (Yes, you can do scripting inside some maven plugins, but if you do that, I'll come over and sit on your keyboard until you can convince me that there was no other way) Avoid gradle like the plague.

cutler 6y ago

Gradle, please die!

pabs3 6y ago

I wonder if this improves the bootstrappability of Gradle. https://bootstrappable.org/projects/java-tools.html https://bootstrappable.org/projects/java-tools.html

skinkestek 6y ago

So far from what I've seen Gradle has been an exercise in frustration from my perspective: a few people "get it", the rest copy and adapt leaving a mess worthy of an evolution theory for code. Then again, I don't want to be like certain others: the above is just observations from my very limited point of view. Maybe in a year I love Gradle the same way I love Java today after initially finding it almost insane. After all there are some seriously smart people using Gradle and thinking I'm smarter than all of them would be some serious hubris from me.

oblio 6y ago
> a few people "get it", the rest copy and adapt leaving a mess worthy of an evolution theory for code. Even better, geological layers :-))

Shadonototro 6y ago

my OS boot faster than gradle, it says a lot about why people "hate" working with gradle projects