Investigate Gradle Tooling API support

[fwcd]

The current solution to find the dependencies of a module/project invokes Gradle from the command line and parses the output:

https://github.com/fwcd/KotlinLanguageServer/blob/322594f491369f51fdda33295101098d81d5bf3d/src/main/kotlin/org/javacs/kt/classpath/GradleDependencyResolver.kt#L54-L62

A more elegant solution, however, would be to have direct, programmatic access to Gradle's APIs in order to fetch a list of dependency JARs. Both Eclipse and IntelliJ IDEA have custom project models inside the Gradle API that fit their specific use cases, but which can be used externally too (EclipseModel and IdeaModel). Unfortunately, these do have some limitations regarding Android support, which is why the current solution involves a custom Gradle script that is invoked as described above. Instead, a custom model could be built using the Tooling API.

Resources:

• The tooling API should provide a way to get the dependencies of the project gradle/gradle#4215 (comment)
• https://docs.gradle.org/current/javadoc/org/gradle/tooling/provider/model/ToolingModelBuilderRegistry.html (Tooling API extensibility points)
• https://stackoverflow.com/questions/40739674/external-registration-of-tooling-api-custom-models
• https://github.com/gradle/gradle/blob/38e0df22ecff6c894f5c3eeecb94106e2ba557ff/subprojects/docs/src/samples/toolingApi/eclipse/src/main/java/org/gradle/sample/Main.java#L28-L28 (EclipseModel sample)
• https://github.com/gradle/gradle/blob/38e0df22ecff6c894f5c3eeecb94106e2ba557ff/subprojects/docs/src/samples/toolingApi/idea/src/main/java/org/gradle/sample/Main.java (IdeaModel sample)
• https://mvnrepository.com/artifact/org.gradle/gradle-kotlin-dsl-tooling-models/0.18.1 (DSL tooling models)

[vasiltabakov]

You can use Android's own models via the Android Gradle Plugin:

compile group: 'com.android.tools.build', name: 'gradle', version: '3.2.1'

https://google.github.io/android-gradle-dsl/current/

This way you'll have access to say AppExtension and do everything you do in your custom Gradle file but with more control indeed.

[kneep]

@fwcd Hi fwcd. I just happened to find this thread. Do you find a solution to this problem?

[daplf]

@fwcd I started looking into this recently and I was wondering: does it really make sense for us to build a custom model instead of using the existing ones? I understand they are specific to their use cases, but can't we choose the model based on the type of project?

I've played around with the tooling API and we can obviously create one from scratch, but I'm wondering if it wouldn't be too much of a hassle, since we would need to maintain it as well (not to mention, the model would basically support all kinds of different projects, which might become a mess IMO).