John Murph wrote:
In order to implement support for listening to TestNG, I will need to
implement org.testng.ITestListener. This entails Gradle depending on
TestNG. The positive is that TestNG would then be in the lib
directory of Gradle, and would "just work" the way it does for JUnit.
The downside is that I'm not sure that a different version of TestNG
could be used (can a different version of JUnit be used?). What does
everyone think (Tomek, I'm looking at you...)?
I think we should aim for the situation where the test task uses
whichever version of junit or testng is declared in the testCompile
configuration. We should do this for the groovy and scala tasks as well:
dependencies {
testCompile ':groovy-all:1.6.7', ':junit:4.8'
}
It should even be possible to declare the version of java to use:
dependencies {
compile java(1.4)
}
And we should do a similar thing pretty much any task which uses an
external tool of some kind. For example, for the jetty, checkstyle and
codenarc tasks, it should be possible to declare which version of the
tool to use:
dependencies {
jetty ':jetty:7.0.1'
}
I don't think we would necessarily support every possible version of
every tool, but would aim to support a reasonable range of versions.
This feels like some general capability that the plugin infrastructure
should provide, where there is some way for the plugin to declare how it
is composed. For example, the java plugin could be split into a few pieces:
- public domain object APIs, including the Test task and TestListener
interface.
- internal tool APIs, such as the TestFramework interface.
- tool implementations, such as a junit or testng based TestFramework
impl.
If there were some way for the build script for the java plugin to
declare this, then Gradle could take care of wiring together the pieces
at compile and at runtime with the correct classpath.
As per usual, none of this helps you solve the problem :)
One option, for now, is to use Groovy to dynamically implement
ITestListener at runtime, based on a classpath built from the
testCompile configuration. Another is to defer the support for
TestListeners with testng until we've sorted out some of the plug-in
infrastructure. I don't think we should force a particular version of
testng on the user, this feels like a bit of a backward step.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
