On Aug 3, 2009, at 9:09 PM, Steve Appling wrote:
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?
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.
Traditionally in Maven and in Gradle, tests were run against the
classes dir because passing the test was a precondition for building
the jar (jar depends on test). This happens to have just changed in
Gradle (over the weekend). Jar no longer depends on test and there
is a set of new tasks starting with "build" that will both test and
compile.
Test, however, is still running out of the classes dir and not off
of the jar. I'm not convinced that this is wrong, but we should
allow you the flexibility to change it. The JavaPlugin adds the
classes dir to the testCompile configuration (see JavaPlugin.java
line 245 in the trunk). The DependencyHandler doesn't have a good
way of removing dependencies only adding them. Perhaps you could
replace the testCompile configuration with a copy filtered using one
of the filtering forms of Configuration.copy. There needs to be a
better way of customizing things like this.
I'm working on integrating dependencies and artifacts into our
DomainObjectContainer logic. As part of this you will be able to
remove dependencies.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
