Maven is so painful, though. Isn't Gradle an improvement on Maven?

Is your assumption that the learning curve on Gradle is higher than that of Maven?

I ask as someone who endured both tools/ecosystems and is intrigued with the idea of moving on to a system like Bazel.

He is just grumpy at Gradle, he does it in every possible thread that even mentions Gradle's name.

Which is especially sad because he fails to even understand what Gradle does (see his comparison with Ant which is just completely inaccurate. Gradle has a proper build graph (actually better than Maven at this - there is never a need to do a clean install in Gradle, but you often have to do it with maven to get the proper output) it operates on)

Yes, agreed. Gradle has outgrown Maven core dependency management features-wise. I wrote back to him, interested in your thoughts.

Not at all, it is a tool designed by those that haven't learnt the Ant lessons that are the reason Maven come to be in first place.

Also they are very keen breaking the DSL language every couple of releases, and before Kotlin based DSL, had to come up with a background daemon to cache Groovy execution, due to its performance, or lack therefore.

So far, I never had any reason to try out Bazel.

I am sympathetic. Declarative programming is _conceptually_ pure. I find in practice, it always makes the core hard things it intends easy and all other trivial matters a torture exercise (see XSLT.) So I can see why you'd reject a goofball imperative programming language like Ant made from XML. I also have had 'sharp edges' experiences with the Gradle Daemon, which struggled to deliver on the build acceleration promises in any case, so I share your frustration there as well.

Gradle and Maven have one rare superpower, maybe you could lump Ivy in there, which is to navigate and cache maven repos to build dynamic classpaths. Java is like a 10-ton elephant hurtling downhill on one foot on a squeaky old rollerskate. Somehow it manages to stays up, but it's always a near run thing whether it crashes. I appreciate that Gradle continues to make incremental advances that keep the elephant up. You complain that Gradle keeps breaking the DSL, but they have to navigate new Java, Groovy, and Maven releases that have relevant feature developments. It's a 16 year old program, it's going to either change or die. I look at JavaExec and consider the power of all it does expressed in such a simple way. Just that one feature makes Gradle tough to beat and worthwhile: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Jav...

Here are the recent-ish feature adds that I found super impactful and that improved the way I worked with Gradle and the overall quality of my builds:

* https://docs.gradle.org/current/userguide/sharing_build_logi...

* https://docs.gradle.org/current/userguide/platforms.html

To me, the fact that Gradle as an organization has been able to keep doing updates over years and make a niche business out of that product has been laudable. I think the way they positioned themselves as thought leaders during the whole Log4Shell fracas was really excellent, and I appreciate that paying them for support mostly means you get their best performance tools and training. I'm skilled enough after a lifetime with the tool that I can do an ok job at performance, but I'm sure things would improve if I could pay.

Bazel is a huge step up complexity wise, and as far as I can tell, it would not be useful for "watcher mode" style builds the way gradle is. If anyone from Gradle, Inc. reads this:

* I like the idea of hermetic builds and reproducible, cacheable builds touted by Bazel, but I also want my ability to use the watcher mode to script hot redeployments and manage local test server lifecycles like I can do in Gradle. Could Gradle be morphed or have a constrained mode somehow to be able to do both those things? EDIT: OMG, maybe you are already headed this direction! https://blog.gradle.org/declarative-gradle-first-eap

* It seems to me that software supply chain in the Java ecosystem could use a package management expert like you. I would love it if Gradle had its own, private for-pay repository that contained a trusted subset of artifacts that you certify and watch new versions and do independent code quality checks and 1st party code reviews (AI-assist ooh la la!) If we can keep our builds to your trusted set, we could have a lot of confidence that our software supply chain is safe. Maybe you could charge customers to add more artifacts to the repo that you approve of quality-wise and then validate and serve going forward.

I don't like the way public maven repos are centralized that we blindly trust and give our telemetry to and would love to point my builds at a private repo.

Yeah, and if Google hadn't used Go themselves, it would've also fizzled out.

Any halfway non-horrible tech just needs enough funding and usage from some company to become mainstream.