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.
