Adam Murdoch wrote:
Paul Speed wrote:
While we are on a similar subject, I will relate another test
frustration I had when moving to Maven and have not found a gradle
solution I like yet (though I've since dropped maven). I think the
proposed integration test idea may be related.
One of my modules is a utility library that amongst other things has
a bunch of reflection utilities. Another module we have implemented
some junit extensions to make testing a little easier... it leverages
the utility library.
Eating our own dog food, some of the unit tests for the utility
package rely on the junit extensions.
In ant, this was easy. Everything was compiled then everything was
tested. Packaging of the separate jars was just a few lines of ANT
script and lacked any package dependencies, etc. ala maven.
Even though "util" compile has no dependencies on "junit-ext", Maven
and Gradle see this as a circular dependency (and from a certain
perspective, rightly so). Because "test" has to run before
packaging, the overall dependencies are circular: util package
depends on junit-ext package which depends on util package. When
really it is util test depends on junit-ext package... if there were
a post-package integration test phase then I might have a clean way
of working around this issue.
I suspect this would all just work now that packaging does not depend
on test. Running 'gradle build' would compile and jar junit-ext before
attempting to testCompile and test the util project, and all would be
happy.
This would make an excellent test case, too, for our java project
lifecycle integration tests.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email