That's a feature not a bug. Gradle has phenomenally good documentation. I wish Google kept that level of documentation up for their plugin, or for any part of Android in general. Large swaths of the Gradle user guide are not applicable to the Android plugin because they are for other language specific plugins. The core of the user guide is only a few chapters long and well worth reading.
I was actually excited when I saw the size of the documentation. I really was, and I read it several times over the year.
And then one day, I realized that the web site that I always get back to in order to fix my build files is Stack Overflow, not gradle.org.
The fact that the documentation is so big is an issue, not a feature, because at this size, it's just too big to navigate, contains extreme amounts of redundancies between sections and basically, is not usable in this form.
You know your tool has a problem when the only way to fix problems is to search Stack Overflow.
This. Like most folks here, I like learning new things. I learned Ant a long time ago, and then Maven (to GP's point, learning Maven was NOT trivial). When I started through the Gradle docs and realized that it's a DSL written in Groovy, I had to open a new tab in my browser and start learning Groovy. Now I'm thinking to myself: "Great. In order to really grok Android Studio, I need to learn Gradle. To grok Gradle, I need to learn Groovy." As I mentioned in a previous comment, with all there is in this life to learn, I just can't bring myself to learn Gradle when I already know 2 other Java build tools :)
You're quite right to avoid learning Groovy, especially with its lack of documentation, but Gradle doesn't really use Groovy. It bundles Groovy, and the Gradle build scripts you write are parsed as Groovy code, but typical build scripts only use a small subset of the gigantic Groovy grammar. I've yet to see an open source project's build script, even Groovy's itself, that drops out of the Gradle DSL syntax to do something procedural using Groovy. The whole point of Ant, Maven, etc is to do build declaratively instead of procedurally. In the small number of instances where you do need to, you're better off using Java or any other JVM language you want to configure the build via the Gradle API.
Not only that, but I suspect Gradle won't use Groovy to parse the build scripts for much longer. Those scripts conform to a rough CSS-style syntax that Gradleware could easily replace with their own custom lightweight parser calling Java 8 lambdas. Given that they replaced virtually all the Groovy in their codebase with Java when they upgraded to Gradle 2.0, the next logical step is to eliminate dependence of the Groovy parser as soon as they can.
Gradle documentation is 66, but Android's gradle plugin is only a subset. Plus, gradle _is_ simple and easy to use in the standard scenario of a run-of-the-mill Android app.
It's when your app becomes more complicated (product flavor's for example), that you need to read and understand the gradle documentation. If this is the case, then you are not a novice and 66 chapters of docs is a blessing not a curse.
and Again _the Android gradle plug-in only supports a subset of gradle_!
I was under the impression that the "Android Gradle plugin" is a plugin to extend Gradle's behavior? So really you're dealing with 66 chapters plus Google's wildly-insufficient Android-plugin documentation.
