Comment by agilob | Hacker News Reader

Comment by agilob | Hacker News Reader

Parent Full thread

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.

Also seems like a horrible idea to use a custom DSL for the configuration. Just another curveball to throw at you.

XML, yaml, toml, json, something else standard and well known would have been nice.

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.

Yeah, a build specification is essentially 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.

Kotlin is an alternative now, and it's great.

Reply on news.ycombinator.com