6 ms·
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
by crossroadsguy 6y ago
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.
- agilob 6y agoI 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.
- this_user 6y agoGradle has unfortunately gone the way of Maven in terms of becoming more and more of an unnecessarily complicated time sink.
- levosmetalo 6y agoSorry, but maven is an order of magnitude better than gradle. In most cases it just works and is blazing fast compared with the alternatives.
- pjmlp 6y agoWhen Gradle advocates tell it is faster than Maven, they usually let it off that Maven doesn't require a backgroud daemon eating away GBs to be fast.
- bitcharmer 6y agoI 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).
- njitbew 6y agoThe 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.
- jpgvm 6y agoYes, 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.
- deleted 6y ago[deleted]
- pjmlp 6y agoThanks to Gradle, Android is probably the only platform where there is always a talk about how to improve build speed for the whole platform. Do you think Scala, Rust or C++ build times are bad? Wait until trying a medium sized Android project with Gradle, without using a gaming rig. I did the same, Android now only via mobile Web or NDK.