4 ms·
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 updat
by agilob 6y ago
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.
- charrondev 6y agoAlso 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.
- jorams 6y agoI 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.
- fiddlerwoaroof 6y agoYeah, a build specification is essentially a DSL.
- zmmmmm 6y agoIt'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.
- saurik 6y agoI 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.
- zmmmmm 6y agoI 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.
- occz 6y agoKotlin is an alternative now, and it's great.