Controlling Gradle daemon via tooling api

Until now I did all my testing by applying plugins to a Project created by ProjectBuilder and well … executing a build on the command line. Thanks to the gradle-tooling-api the second part got easier, as I can programatically do that now in a nice JUnit environment. BUT, it uses Gradle daemons, which is a problem because I try to also have a code coverage.

So far I have been able to add the jacoco agent to the daemon by simply providing the jvm arg as system property within the test task. This will successfully start the daemons with the jacoco agent, and proves again how awesome Gradle is, because it is a single line of code :slight_smile:

But now for my doubts / problems: 1. Gradle daemon outlives the test; Other tasks might get executed using the jacoco agent. 2. While I’m executing my test, some other build might start using my daemons. 3. Gradle daemon might already be started, without the jacoco agent. 4. because the Gradle daemon stays alive it will still keep a file lock on my agent jar file located in my local build dir, so a subsequent call to ‘gradle clean’ will try deleting a .jar file still in use by the daemon.

my current workaround is to simply call ‘gradle --stop’ before and after test and finally call ‘gradle jacocoTestReport’. So I have a total of four calls instead of one and I might shutdown a daemon currently in use by another build.

So finally my question: Can I somehow create a “private” daemon via the tooling-api, so that no other build can hijack my daemons and stop them once I’m done, eg: when calling ProjectConnection.close()

test {
    ext {
        daemonJacocoExecFile = new File(buildDir, 'jacoco/daemon.exec')
      doFirst {
        // jacoco plugin adds a configuration called 'jacocoAgent' with a single dependency towards the agent
        // but we actually want a jar within this dependency. Fortunately the existing build is unpacking it for us and
        // stores the jar within the build folder, calling jacoco.agent.jar returns a File with the path.
        // as we don't want to resolve any configurations outside execution phase we do this within an action
        systemProperty('org.gradle.jvmargs', "-javaagent:${jacoco.agent.jar.absolutePath}=destfile=${daemonJacocoExecFile.absolutePath}")"adding jacoco agent to jvm args for daemon: ${systemProperties['org.gradle.jvmargs']}")
jacocoTestReport {
    executionData += files(test.daemonJacocoExecFile)

Use and your daemon will be tied to this Gradle user home directory. You will probably need to keep your call to ‘gradle --stop’ there for a while until we make this possible in the API.

I have similar issue when running functional tests for my plugin with a few different Gradle versions (every daemon stays in memory). Has it been already implemented? If not is there a ticket which I could follow?