The other, possibly more accurate rendering of the project layout is for tests that rely on WicketTester to be in a separate module from core, which is more accurate about their intent and pushes the heavyweight tests out of core so the real unit tests are run more often. wicket-core would thus keep it's current dependencies, a wicket-tester artifact would rely on core, and either in that module or as a separate module is where the integration tests that rely on WicketTester would live.
This is the way that Maven does it's own internal testing. There's a lot of links on integration testing on the net, [1] being the primary one. [1] http://www.sonatype.com/people/2009/06/integration-tests-with-maven-part-1-failsafe-plugin/ On Aug 15, 2011, at 3:14 PM, Brian Topping wrote: > Hi guys, > > After doing some analysis of this, I have some good news. First, for the > analysis! > > (Base)WicketTester, it's usages and dependencies is an interesting problem. > WicketTester has dependencies on classes in wicket-core (Component, Page, > etc), but then it's used in the unit tests that validate the very same > classes that it depends on. Going a step further, it also has > WicketTesterTest, which tests that WicketTester is valid (presumably before > testing the validity of the rest of wicket-core). > > Also, wicket-parent defines that a test-jar is built for all children, first > added in 2008 and attributed to WICKET-1641[1]. But it doesn't make sense if > other projects are not depending on each other's tests. > > I tried a few different solutions, including [2] and various permutations of > includes/excludes on that theme. That would probably work, but the > wicket-core POM is included in the wicket metadata, which is incorrect since > in the final artifacts, wicket-core-test should have a dependency on > wicket-core. (This is really a bug in maven-jar-plugin, since every test-jar > should have a dependency on the code that it tests....) > > What I would propose is to get rid of the test-jars being created across the > project, then create an artifact with WicketTester in it. If there is a > desire for the POM of this new jar to depend on common and have a different > ${project.name}, I could easily create a plugin that will do that. > > Thoughts? > > [1] https://issues.apache.org/jira/browse/WICKET-1641 > [2] http://maven.apache.org/guides/mini/guide-attached-tests.html
