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.
> 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...
As someone who has regrettable know about Gradle long enough to remember when someone actually thought Groovy might be "the future", the idea that they might support a different off-the-shelf syntax had never occurred to me... OMG you have made me so excited to try escaping.
How are you finding build/packaging times with gradle + kts building a kotlin project?
Gradle can be impressively fast (i’d hate to use a gradle build without the distributed build cache feature these days, what a difference), it can be reasonably easy to identify slow parts of a build (digging through build scans isn’t too hard). When it comes to extending it, groovy is actually pretty comfortable for making little doo-dads to assemble some shell scripts from templates, or populate an h2 with some build metrics, or whatever you need, but all in all i think i’m over gradle.
The speed is hard to keep on point, requires constant babysitting in a medium or large team and the learning curve really requires a reasonable working knowledge of groovy first (or kotlin - i haven't used the kts facilities) and a lot of java developers just aren’t interested in learning properly so they hack something in which leads to band aids that get hairy easily.
Speed is fine, in the larger monorepo projects I have worked on implementing plugins using the worker architcture and paying attention to parallelism by splitting things into sub-projects appropriately always kept build time reasonable.
You are correct that the biggest problem is that many people treat it as a distraction/unimportant part of their workflow and then wonder why things go badly.
As the most senior member on most teams I am on I take it on myself to take charge of the builds, CI and other tooling to ensure this doesn't happen and all engineers are productive. Unfortunately that isn't a solution for everyone but IMO it's how it should be, you make yourself a 10x engineer by magnifying the performance of your other team members.
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, 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.
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.
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.
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.
It's only really "custom" if you don't know Groovy. Plenty of build systems invent a whole custom language for it so it is one step better than those - at least by the time you do learn groovy you have picked up a transferrable skill.
I do think that one of the big problems with Gradle is they try to operate under a pretense that you don't need to learn any Groovy to use it. The reality is you can get just far enough to get yourself in trouble and then suddenly you are mired in inexplicable problems, and just start hating the tool.
I mean, it is only really NOT "custom" if you have even considered using Groovy for anything other than Gradle; and like, while I remember there were people who seriously thought Groovy was "the future" 15-20 years ago, they were wrong.
I wouldn't agree with that. Custom would imply there's literally only one purpose for the language. Groovy has a lot of relevant applications outside of gradle scripts. It's great for testing any JVM language, the basis of things like Jenkins pipelines, a generally useful extension language to embed in any JVM based software, and a myriad of other potential uses including full application development as a first class JVM language. Just because you personally wouldn't prefer to do those things doesn't change the general nature of what it is.
I have the exact opposite experience. Been on tens if not 100+ Java projects over the last 20 years and 99% of developers I worked with moved away from Gradle after migrating to it from Maven. It's just harder to work with. Maven is super low-maintenance in comparison (and just works).
And Maven makes writing custom build logic just hard enough to discourage people from doing so, which is a very good thing, from my experience of having worked with Gradle for 5 years or so.
Maybe that is the case if you are working on a project that is large enough to have a dedicated build engineer who stays on top of the Maven situation. But in my experience Maven has been an absolute nightmare to work with for me and others on the teams that I have been on. I don't know how many days have been lost to trying Maven to do one simple thing correctly. And I can tell you that more than once was I eventually so fed up that resorted to using the Ant plugin. That was usually able to solve a problem in five minutes that I had already spent a day on trying to get Maven to cooperate.
That being said, when I switched over to Gradle almost ten years ago, it was still only a marginal improvement, but an improvement nonetheless. Unfortunately, things only seem to have gone downhill from there.
You represent the 1% of java developers who think Gradle is better than Maven. And that's OK because as with everything else there is an element of personal preference to everything.
But that doesn't change the fact that overwhelming majority of professional java devs avoid Gradle like the plague.
And no, we don't have a dedicated maven guy in every project. Maven is just too simple and well understood for that.
To support java 16 all I had to do was change the release tag in my compiler plugin and everything just worked. Didn't have to ugprade maven, didn't have to upgrade the compiler plugin. Gradle users had to wait until they released another entire major version with all the churn that entails.
I'm guessing you only read the issue or title on that link, because the second comment on that issue is from one of the Gradle maintainers suggesting using toolchains (which I linked to), with follow ups from various users advising some success, allowing them to target Java 16 while running Gradle on an earlier, supported version.
The last comment by a gradle team member, before closing the ticket says "... you won't be able to run Gradle 6.8.x on Java 16". Some users having some success compiling isn't really a ringing endorsement of a build system when it's clearly not working completely.
The problem is that it is super easy to modify a Gradle build scripts, but also super hard to get it right (e.g. understanding of configuration vs. execution phase, concept of configurations, task dependencies). As long as you don't touch the build script, Gradle is superior to Maven in _so_ many ways.
Yes, it has what I would describe as a cliff learning curve and I think that is it's biggest drawback. One understands Gradle or one doesn't and that is pretty far from ideal.
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?
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.
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)
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.
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.
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.
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.
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.
> 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.
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.
Again, Spring is usable with Maven as it ever was.
Pivotal is always chasing the latest fad in Java community as means to attract developers, almost every JVM guest language and build system has at a given time had Spring first class support, then it was removed when it stopped being cool.
Sorry, but Netflix could be using Brainfuck and it wouldn't affect anything outside their building, without any relevant meanint to the actual quality of their product.
If anything it just proves that Netflix is able to deliver despite the tooling they happen to choose.
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/...). 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)
> 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.
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.
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.
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.
> 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.
If it were a few percent, it would matter, over days and weeks of development. But it's not a few percent. The difference between spinning up gradle from scratch to gradle using a running daemon is substantial. You can cough up money and resources for their Enterprise edition to get the shared build server, but you add an incredible amount of complexity and difficulties with reproducibility.
Actually, gradle will be likely faster even without the daemon as it can parallelize tasks (as opposed to maven that can only parallelize multi-repo projects)
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.
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.
The IDE doesn't invoke the build tool, it extracts the project structure from it. If the build tools has a sane model (i.e. maven or a gradle build that's maintained with discipline) then it will get an accurate picture of which sources should be built depending on which other ones, and can use that combined with its own knowledge of which files have been edited to do incremental compilation and even e.g. re-run affected unit tests but not others.
> 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.
Using incremental compilation for release artifacts is a huge red flag IMO - how will you reproduce that same build in the future? So using it for local builds is a tradeoff: you get to iterate faster, but you have a divergence between your release build and the one you're iterating with. IME it's usually worthwhile (provided you're still running your full test suite as part of your release build).
So given that there's going to be a different code path running, is it important to be using the same build tool in those two cases? IMO no - the difference between maven building my code for release and my IDE building my code incrementally based on my maven project model isn't really any bigger than the difference between gradle building my code for release vs gradle building my code incrementally. If anything the fact that maven exposes the project model in a stable form (such that my IDE is able to use it) is an argument that those builds will be more consistent.
But you can use gradle to build from an IDE and gradle will do incremental builds correctly and fastly (as opposed to maven where you should be doing clean install).
> But you can use gradle to build from an IDE and gradle will do incremental builds
Not true in my experience. For a gradle project intellij offers me the choice of building with intellij (incorrect) or gradle (slow - the actual compilation may be fast and incremental, but it takes a couple of minutes to start up, build the project definition, and so on. I'm sure this is because me and my colleagues are using it wrong and some theoretical gradle wizard wouldn't have this problem, but it's been the behaviour of every gradle build I've had to use in actual real life).
> correctly and fastly (as opposed to maven where you should be doing clean install)
Not my experience at all. Maven may be less incremental but miscompilation is a lot more common with gradle. And more to the point, IDE-based build is a lot more reliable with maven than with gradle, to the point that any slowness of the maven-based build is irrelevant.
I do agree that it is harder to correctly parse/import a gradle project into an IDE (though I haven’t got a bad experience lately), but when running the actual build tool, gradle will correctly identify previously compiled files and the like, and clean is absolutely not required. It is not true of maven.
But I do apologize, in my prev-prev reply I was way too cocky and wrong; actually building with the IDE is much more common (but depending on the project it can introduce subtle bugs, so do try out the build tool built version as well from time to time)
And build speed on large projects do matter, so there is a point where I think gradle is worth using over maven, because it can mean an order of magnitude reduction in build time.
Probably because it doesn't really make sense. If you have to build multiple projects as part of your build, they should probably be in the same repository, or you should be consuming artifacts already created from other project builds.
For example with Maven if you run any task from the sub-project which depends on adjacent sub-project, maven will look for it in ~/.m2/repository. So you have to mvn install every time you're doing any change in any sub-project which is PITA when you're changing many sub-projects simultaneously (and if you did not mvn install, you'll have old version in repository and new sources in IDE and things go wrong way in a completely non-obvious manner). But if you're running maven commands from root pom, sub-projects will properly reference each other. So the proper way is to run all commands from root repository and specify -pl. But then you'll run into other issues, as not all plugins will work correctly this way (for example mvn exec:java).
With gradle it just works. You're running command for any sub-project and gradle will properly find any dependant sub-projects, build them, put them into classpath, etc.
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.
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.
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.
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).
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.
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?
These days the Kotlin DSL is treated as a first class citizen and you can find examples for most common tasks in either language. But Groovy is pretty easy to pick up too, you definitely don't need to know it before you start using it with Gradle.
Aside from the performance implications, Gradle excels when used with more complex builds with many steps. If Maven works for your use case, your build scripts aren't unmanageably long, and your team doesn't mind XML, there isn't much of a reason to switch.
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.
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-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.
This is funny, because I have the complete opposite experience. Yes, it took me an afternoon to find my way around Gradle. But ever since I really appreciate their documentation. It is to the point, well written, contains code samples (which I believe are unit-tested, so they the code samples are always up-to-date), contains examples in both Groovy & Kotlin, and I could keep going on. A good entry point, for example, is Build Script Basics (https://docs.gradle.org/current/userguide/tutorial_using_tas...).
> But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation.
One thing that keeps disappointing me is the utter lack of reference-style (API) documentation.
Sure, the conceptual documents contain examples. But if the example isn’t clear enough, you’re completely on your own.
You are probably doing a bit simpler stuff, if that basic tutorial suffices you. I should have maybe added that I do Android development with Gradle. There you don't as much start with an empty build file to write the tasks to compile your project, but instead have to navigate a pre-existing large build file and figure how to correctly use the Google and Gradle interfaces to integrate to the Android build tools, such as the dreaded AGP (Android Gradle Plugin). Which by the way is actually mostly undocumnented AFAIK!
I know nothing about Android development with Gradle (or Android development in general, for that matter). I feel that is where a lot of negativity in this thread comes from. But then it's not per-se Gradle who is to blame; it's this specific use case of Gradle with Android which apparently is giving people a poor experience (e.g. lacking documentation).
> You are probably doing a bit simpler stuff, if that basic tutorial suffices you.
I've written a couple Gradle plugins, one of them was to build and test programs in our custom DSL. This exposed me to all facets of Gradle, because whatever Gradle offers to compile Java, Kotlin, ... you will most likely use for another language as well. I could not have written these plugins without the Gradle documentation. But again, it's totally unrelated to Android development.
The problem is not all developers have such a nice experience. Maybe the reason is underlying assumptions - they can really help in learning or become a really big obstacle, if one isn't aware of them. That or another, my several attempts to grok Gradle from existing scripts and documentation still fail to produce understanding.
The documentation I'm missing is: what tasks, sourcesets, etc. exist by default? Where are they defined? I don't want to do some kind of runtime introspection in a build environment shell to find out what the project build does, I want a static list of all the tasks and which depends on what.
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...
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.
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.
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
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.
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.
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.
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.
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
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.
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.
It's the main reason people use Grade but it's a trap. A build definition that allows people to inline arbitrary snippets of code anywhere will always end up as unmaintainable unless you have very strict rules about what kind of code is allowed where - and once you have those rules you end up with something that's no more flexible than Maven.
Strong agree. The thing about Maven is that it requires us to build a project model, then it executes the model. That means it's possible to reason about what will happen based off the completed model. It doesn't matter whether the model is encoded in XML or generated in code: the important bit is that we (and our tooling) can inspect the model.
Gradle _almost_ does the same, but it allows execution of arbitrary code in too many places -- like with parsing Perl, we can't discover the model without also executing it. Hence the trap.
I somewhat agree. I feel like when I am trying to get some more complex build tooling worked out being able to prototype with inline tasks before developing a plugin is a big win.
Doing such prototyping in Maven is quite arduous in comparison.
Writing inline code (tasks) into build scripts is not recommended and, in the words of Cedric Champeau (former Grrovy committer and Gradle Inc. employee): "I repeat, nobody should every inline build logic in a build script. Nobody." [1]
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...
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?
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.
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
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
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.
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.