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 trivi

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.JavaExec.html 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_logic_between_subprojects.html#sec:using_buildsrc https://docs.gradle.org/current/userguide/sharing_build_logi... * https://docs.gradle.org/current/userguide/platforms.html 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 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.