Bear with the explanation, I want to make sure our use case is explained…
We create a plugin JAR which needs to maintain compatibility across multiple versions of Gradle (like many of you probably do). In order to verify that we haven’t caused major problems (such as the build will blow up with a certain version of Gradle) we set up a compatibility test suite in a subproject.
We run one test task per supported version of Gradle, which passes in the distro URL as well as the classpath to use for our plugins. Inside the JUnit tests, we use the tooling API to run the different build scenarios we want to test.
Our discomfort comes from the options for kicking off the Gradle build from the tooling API.
Our current choice is to set the ‘embedded’ property on the GradleConnector. This is an internal property so there’s the first point of discomfort. The other is that this runs within the test process rather than forking. I don’t know if this will ever cause us problems, but it doesn’t seem ideal.
Use the GradleConnector default (the daemon). This results in one daemon per supported version of Gradle (currently 3). I don’t see that as bad in itself, as long as those daemon processes don’t cause any further problems.
However, because the daemon is long-living and holds locks on both the directory it was last used in and any JARs it loaded into its classpath, we run into issues on the next execution when we try to cleanup the results of the previous build. This can happen in two places:
- The plugin JAR created in the root project. We are directly using the one built into the ‘libs’ directory. 2. The temp directories that each test project is run from. These are locked presumably as the working directories of the daemons.
There are probably some things that would help, for instance, copying the plugin JAR to a different location so we can clean up the ‘libs’ dir. Another thing that could help is if the daemon didn’t use the settings dir as its process working directory. Maybe it could use something in GRADLE_HOME (e.g. /daemon/wrkdir/)
However, I get the wider feeling that we’re either misusing the tooling API or just on the completely wrong track… Does anyone have thoughts on how to approach this situation?