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.

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.

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.