"modern, idiomatic, as-God-intended method of Gradle usage" Which changes literally every release, and half of my gradle tasks (already cobbled-together voodoo

"modern, idiomatic, as-God-intended method of Gradle usage" Which changes literally every release, and half of my gradle tasks (already cobbled-together voodoo incantations) for shaded jars, dependency copying, integration tests, etc ... as in common tasks for build systems ... breaks. That said, building is HARD, and man is it HARD to pick up the nuances. Really there should be a massive standard feature set for build frameworks that every build framework has to document an example of. Ant was too XML-y, and too disorganized. Then came Maven (still XML-y) but way too rigid and limited. Then came gradle, which had potential, but largely is a failure. Gradle is well supported by IntelliJ. That's why it's the choice currently. I tried IntelliJ with Maven and it failed with some basic stuff, so it's gradle or ... nothing. The caveat, again, is that, like languages, there are two types of build systems: those you complain about (because you use them) and those that aren't used at all. I have not used bazel, pants, or any of the newer build frameworks. Make is both zealously pushed by neckbeards, but curiously used almost nowhere outside of C (a bad sign) and I've read really good "make sucks because" posts. It speaks to the general constant cycle of suck in software that building code, something that we've done in software for a half-century plus, has very little to show in the way of evolution and growth. But that's because there is nobody that has proper economic investment incentives. Even google probably underfunds Bazel. I almost wonder why google and those places don't have two groups / virtual companies that compete to be the build system based on project usage (I also wonder why large companies with a dozen datacenters don't have them compete against each other internally for customers / project funny money).