Depending on what your integration test does, you might be better off with the
ProjectBuilder. This simply creates instances of Project which you can apply
your plugins to to test them. It has the advantage that everything runs
in-process and you don't need a Gradle distribution to make it work at runtime.
I've started with ProjectBuilder, but it's really not that useful. It
seems to only allow you to test plugin initialization. Not bad, but I
don't want to stop here.
If you want to actually run a build, you're pretty much stuck with the tooling
API for now. It might be useful for us to add some kind of test fixture for the
tooling API, so that your test can create a light-weight implementation of
ProjectConnection or perhaps BuildLauncher.
It's an integration test, so I don't see it as a bad thing to perform a
full Gradle build. If the daemon would work for my use case, there would
wouldn't be much of a complain. Of course, better testing provisions
would surely be welcome (the daemon might complicate coverage reporting).
In the meantime, a workaround you can use is to switch the tooling API to
'embedded' mode, via an internal API. This will run the build in the test jvm,
rather than using the daemon:
DefaultGradleConnector connector = (DefaultGradleConnector)
GradleConnector.newConnector();
connector.embedded(true);
Thanks! That works like a charm!
The test now runs magnitudes slower, but at least it does no longer fail
for repeated runs.
Cheers,
Marco
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
