Sometimes I feel they should stop the development of all new features and concentrate exclusively on performance improvement (which, fortunately, is not neglected in this release).
I would say that they should not stop the development of all new features, but rather they should spend more time designing those features, so they don't have to change them in the future (making old variants obsolete and broken in the end). But modern software development is agile, move fast and break things and all that.
I'm yet to see a good explanation for how Gradle should be used. Is knowing Groovy a prerequisite?
I don't know Groovy and I was able to write complicated enough multi-project builds with some custom build steps by copy-pasting snippets from the Internet and applying some common sense. I guess, Groovy knowledge is required if you need to write build plugins.
Everone "learns" Gradle by copy-pasting snippets from the Internet and then having to fix them when they break. And what little I have learned of Gradle over the years was certainly not thanks to their documentation, but other people explaining the concepts in blog posts and tutorials. The Gradle documentation always assumes that you will want to learn the whole build system from ground up. There is no simple documentation for people who see Gradle just as a tool secondary to their actual product that is just built with it.
It is in many ways similar to git. You can't really learn git unless you learn it from the ground up. But git is actually really simple when compared to Gradle, and most people do learn git eventually through using it. But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation.
Oh, and at least git's interface and structure has remained mostly static ever since the original concept by Linus in 2005. Same can not be said of Gradle - I feel like the developer interface is like a sand castle that is washed away every second release, and I assume the internals keep shifting as well. What a nightmare to work with.
> But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation.
You just met him! ;)
For example, the following document has been largely useless to me even though I’ve spent whole days trying to make the examples work for me: https://docs.gradle.org/current/userguide/cross_project_publ...
> You are probably doing a bit simpler stuff, if that basic tutorial suffices you.
I've written a couple Gradle plugins, one of them was to build and test programs in our custom DSL. This exposed me to all facets of Gradle, because whatever Gradle offers to compile Java, Kotlin, ... you will most likely use for another language as well. I could not have written these plugins without the Gradle documentation. But again, it's totally unrelated to Android development.
Aside from the performance implications, Gradle excels when used with more complex builds with many steps. If Maven works for your use case, your build scripts aren't unmanageably long, and your team doesn't mind XML, there isn't much of a reason to switch.
Maybe its just how android is and nothing to do with graddle but still...
EDIT: right, Jetifier too, because that's always a lot of fun.
Basically, as I remember it, every time Android studio updated Gradle, my project broke. No exceptions, even though this was a stock Android Studio project.
Seemingly things are still that terrible? If so, why do you people keep using it?
What problems does Gradle solve which other build-systems don’t solve better