Kotlin-dsl-samples: Introduce API for querying the classpath of Kotlin build scripts template classes via TAPI

[bamboo]

[oehme]

I assume this is about providing a stable gsk-client JAR (similar to the tooling-api JAR) which is able to get the classpath in a forward/backward-compatible way? That would be great, because right now there is brittle "get GSK from the distribution" code in IntelliJ and Buildship.

[donat]

A little clarification on the API usage. I image Buildship querying the Kotlin classpath model via the TAPI and then pass it to GSK via the environment map. This way GSK won't have to do another TAPI query. As a consequence, we spare and extra configuration for the build which can be significant for large for large projects.

[bamboo]

Thanks, @donat.

[bamboo]

@donat what's going to take care of invalidating the model cache in that case?

With the current implementation, the resolver also takes care of detecting changes to the buildscript and plugins block and automatically re-querying the model whenever they do.

How would that work with Buildship providing the model directly?

[donat]

The process is driven by the Kotlin script editor, so Buildship would query a fresh TAPI model for each change in the build script.

[oehme]

@donat I assume by "for each change" you mean "each time the user saves the build script"?

[donat]

Yes.

[eskatos]

Querying the model involve setting some project property and system property.

We are thinking about putting the following in the gsk-tapi jar:

• the model type declaration, aka. KotlinBuildScriptModel
• a helper method to set the right properties on e.g. the client-side ModelBuilder

@oehme, @donat, does that make sense to you or do you have an existing pattern already in use in TAPI client code we could apply here?

[donat]

It makes sense. Apart from the Buildship-specific code where we apply the project preferences on the TAPI connection we directly use ModelBuilder. I suppose your helper method would set some extra JVM arguments on the connection.

[eskatos]

@donat and I had an enlightening chat about this issue.
The main outcome is that there was some confusion about the goal.

Buildship needs to provide the Eclipse-Kotlin support with the script template class (KotlinBuildScript) and the classpath required to load it.

It has nothing to do with the classpath for build scripts that is potentially different for each build script. It's simply the gradle-script-kotlin classpath, which is related to the Gradle distribution. Computing that classpath won't be costly as we won't need to configure any project. No need either for the optimisation trick mentioned ☝️.

So, basically we need to expose a TAPI model builder for some GradleScriptKotlinClasspathModel. This model would include a classpath for the gradle-script-kotlin jar and its dependencies. This model builder won't have any system/project properties as input. Pretty simple.

For Buildship not to drag the whole gradle-script-kotlin jar and its dependencies we need to put that model in it's own jar and publish it.

[oehme]

Computing that classpath won't be costly as we won't need to configure any project.

Any tooling model request fully configures the project.

[eskatos]

@oehme thanks! that's what I thought after reading some more code ..

[oehme]

Of course it shouldn't be that way, so one answer could be to improve that as part of this story. The GradleBuild model for instance also shouldn't need a configured project, only evaluated settings.

[eskatos]

@oehme we probably won't handle this as part of this story
I opened an issue for this: https://github.com/gradle/gradle/issues/1977

[eskatos]

A first cut of the model builder is available in #358

I built a distro with it and sent it to @donat for a preliminary evaluation.
Once we validate it works we'll adapt our build to produce a tapi-api jar, see #304 .

[donat]

I integrated the template classpath loading locally and can confirm that it works as expected. We still see the issue with Kotlin-Eclipse not picking up the result of the resolver. I'll contact JetBrains on that matter by reviving the https://gradle.slack.com/archives/G0DGS35E2/p1491817311440691 thread.

[eskatos]

Model: org.gradle.script.lang.kotlin.tooling.models.KotlinBuildScriptTemplateModel.

In master by e773d0d15942a72bb7fe28192b157480ceaa37cf