Russel Winder wrote:
Hopefully this isn't just a RTFM question . . .
The classic lifecycle includes:
. . .
compile the code of the jar (or whatever) to a directory
compile the tests against the directory of compiled classes
run the tests
create the artifact
. . .
I am increasingly of the view that this way of compiling and running the
tests is the wrong way of doing things -- even for unit tests. I think
the artifact should be made and the tests compiled and run against that.
From what I can see Maven is not able to do this sort of testing. OK
there is an integration-test phase but the directory of compiled code is
always in the classpath of the test compile and execution, which
effectively ruins any idea of running the unit tests with the jar
instead of the directory of compiled classes.
I am hoping that this restriction has not been bolted into Gradle.
So I want to:
compile the classes of the jar
create the jar
compile the tests using the jar and not the directory of compiled
classes
run the tests using the jar and not the directory of compiled classes.
Is there a Gradle idiom/example for doing this?
compileTests {
dependsOn jar
classpath = files(jar.archivePath, configurations.testCompile)
}
test {
configuration = files(jar.archivePath, configurations.testRuntime)
// we really should rename configuration to classpath
}
You could tweak this a bit to filter the classes dir out of the
testCompile and testRuntime configurations:
compileTests {
classpath = files(jar.archivePath, configurations.testCompile.files
{ it instanceof ModuleDependency})
}
Thanks.
BTW Is gradle heading towards Maven's ability to generate websites with
all the various reports? That is a very cool feature of Maven.
Sort of. I want to add a report which aggregates all the other reports
which Gradle generates. It's audience would be the developers of the
project, and so it may or may not be usable as a public website. I never
really understood why the consumers of a project actually cared about
all those reports on the public website.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
