Gradle-launcher-1.12-rc-1.jar not on classpath

You’ll find that there isn’t an analysis call in the tooling api. I find that the configuration phase can be simulated very well by just the ProjectBuilder (part of the ProjectSpec in nebula-test).If I need more, I use the IntegrationSpec in nebula-test, which wraps either the GradleLauncher or the Tooling API.

To test out a custom distribution you have a few options:

  1. point GradleConnector at the custom distribution zip or an exploded image. 2. point GradleConnector at the original distribution you build the custom distribution from, and generate an init script to inject the additional classes you want to test.

For #2, you can calculate the classpath you need in various ways, such as inspecting the test ClassLoader or using Class.getProtectionDomain().getCodeSource() or injecting it from the build. Once you have the classpath, the generated init script can make stuff available via the root project’s buildscript ScriptHandler.

You can do the equivalent of analysis using the tooling API - using ‘ProjectConnection.model(GradleProject.class).get()’.

That doesn’t quite answer the question. Why do you need to add to the classpath.

One option for running the in-memory distribution is to use the Tooling API and use the internal ‘embedded()’ method on the connector: https://github.com/gradle/gradle/blob/master/subprojects/tooling-api/src/main/java/org/gradle/tooling/internal/consumer/DefaultGradleConnector.java#L82-82

There is no public API for embedded Gradle in 2.0.

Thanks Luke. Tried embedded(true) but it still tries to install a remote distribution. Any way to turn this off?

17:08:55.164 [main] DEBUG org.gradle.tooling.GradleConnector - Connecting from tooling API consumer version 1.12 Downloading https://services.gradle.org/distributions/gradle-1.12-bin.zip

Forgot about this.

There’s no way to get the daemon to run from the classes in memory, because it can’t properly set up the classloaders the way it needs to. What you can do is have it use the same Gradle distribution that you are running from by setting the distribution to ‘gradle.gradleHome’.

https://github.com/gradle/gradle/blob/build-type-order/subprojects/tooling-api/src/main/java/org/gradle/tooling/GradleConnector.java#L95-95

Hence the answer to “Why do you need to add to the classpath.” I did try useClasspathDistribution() and got some classpath exception.

I could not find a BuildLauncher method that would give me a org.gradle.BuildResult object. Do u have any examples of using a ResultHandler to achieve this?

You won’t be able to get that specific object via this API.

The best thing to do at this point would be to start a fresh forum thread explaining what you are trying to do, not just how you are trying to do it. It’s very difficult to answer these questions without more context given that there aren’t 1-to-1 direct replacements for the changed API.