[bsder]

Fix the documentation!

Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so.

You need to create a LOT of Android Studio sample projects, and they need to be kept up to date for the various versions of Android Studio. If you did nothing but create "Hello World" in a zillion various flavors (Java, Kotlin, Scala, NDK, NDK with static library on different architectures, etc.) for people, that would be huge.

My specific beef is with NDK projects. Pulling in static libraries and compiling them with the NDK is a mix of magical keywords that sometimes materialize from some kind stranger via chat--generally because Gradle has to shove those keywords to something like CMake--which ALSO has an enormous learning curve.

[dljsjr]

Please don't say that nobody uses Gradle outside of Android devs. We're a shop that definitely does zero Android development and we still use Gradle, the fact that people assume Gradle <-> Anroid Dev is already a huge pain point for us when we start looking for third party educational resources.

[pjmlp]

At our shop we only care about Gradle, because Google forces ud to.

Otherwise we would keep using only Maven for Java projects.

Slower builds and higher hardware requirements for daemon and build cache are not worth it.

[kodablah]

> Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so.

False

[pjmlp]

It is true for us.

If it wasn't forced upon us for Android dev no one at my employer would even bother to learn what is Gradle.

The opinion is that it is the last spot keeping Groovy alive.

[lomnakkus]

Jenkins also semi-recently decided to go with Groovy for their "pipeline" feature. Ugh.

(They may have good reasons, but anything that prolongs the lifespan of Groovy is a bad thing.)

[wendelinsky]

Thanks for the feedback. Docs/samples oriented around Android could use some love for sure. I think one thing we need to figure out is how Google and Gradle can accomplish these things together.

[bsder]

> I think one thing we need to figure out is how Google and Gradle can accomplish these things together.

We refer to that in the corporate world as "death by committee".

You can solve the problem with a GitHub repository and an intern trawling StackOverflow and IRC logs. Choosing not do that sends a signal.

Waiting for Google to "accomplish it together" (aka sometime before the heat death of the universe) is a good way to get replaced.

[lmilcin]

While all Android Studio users are forced to use Gradle only handful will ever need anything more than the basic boilerplate generated by Studio.

My Android projects are mostly private stuff but I don't remember any project that would require any kind of custom build. There is whole plethora of tools. My own calculators for various stuff, app to communicate with my family, apps to manage my electronics (bluetooth, wifi, cloud), apps to manage stuff in my Drive. My changes are mostly adding dependencies.

[pjmlp]

Try to integrate NDK builds or follow up on the continuous suggestions given at any major Android conference about how to speed up builds.

That basic boilerplate is no longer enough and tricks change with each release.

[dcow]

The gradle team doesn't work on android builds. They work closely with Xavier from googles android build tools team on that.