Here is the pattern I was going to build: Project proj-a creates a.jar which contains: -- Interface A which is the API for the jar -- Class AImpl which implements the API -- Class AFactory which creates implementations of interface A
Project a-test creates a-test.jar which contains a MockObjects version of class AFactory which allows unit tests to preload the factory with a mock-object implementation of interface A to be returned by the factory Project proj-b uses a.jar, so needs to define a dependency on a.jar with compile scope and a-test.jar with test scope. My questions: 1) Is there a reason why the API class (interface A) needs to be in a separate project from the implementation classes (AImpl and AFactory)? 2) How do I define the dependencies in project proj-b to ensure that the mock-objects version of AFactory gets used during unit tests? -----Original Message----- From: Tim Dysinger [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 28, 2005 12:39 To: [EMAIL PROTECTED]; Brett Porter Cc: Maven Users List Subject: Re: Cross-project dependencies on unit test code Ok. Let's say we did it that way. We are still faced with the same problem with the maven-eclipse-plugin. Maven-eclipse-plugin does not like having your source and test directories the same. <sourceDirectory>${basedir}/src/java</sourceDirectory> <unitTestSourceDirectory>${basedir}/src/java</unitTestSourceDirectory> I can't do this without using eclipse. The plugin, in this case, would generate a bogus .classpath file. Putting the junit code in src/java is the only way I know that maven will publish your jar so other projects can depened on it. If you just put your tests in src/test, maven will publish an empty jar and the dependant project will fail to compile. -Tim On Wed, 2005-09-28 at 08:42 +1000, Brett Porter wrote: > This has been asked 2 or 3 times this week. IIRC someone was going to > write up their experience doing it? Would anyone like to volunteer to > add it to the wiki? > > - Brett > > On 9/28/05, Raphaël Piéroni <[EMAIL PROTECTED]> wrote: > > Hi Tim, > > > > May you try with something like this : > > wrapper > > +- core-api > > +- core-test (depend only on api) > > +- core-impl (with some test cases - depends on core-api and core-test > > the later with scope test) > > +- use-core-1 (depend on core-impl, depends on core-test at scope test - > > the test cases must not depend on core-impl's tests) > > +- use-core-2 (...) > > > > Then you move all the common test practices to the core-test project. > > > > May that helps. > > > > Regards, > > > > Raphaël. > > > > Tim Dysinger a écrit : > > > > >I have a "best practices" question. > > > > > >I have a multi-project setup with three sub-projects. Two of the > > >sub-projects have tests which subclass tests in the "core" project. > > >However, just having the sub-projects depend on "core" does not expose > > >the unit test code and the build fails with a compilation error. > > > > > >If I put the unit tests into the src/java directory, then the eclipse > > >plugin generates duplicate source directories "src/java" in > > >the .classpath file. > > > > > >I imagine that I could break out all the tests into other sub-projects > > >but that seems clumsy and would double the number of projects in my > > >multi-project setup. > > > > > >How do I deal with this elegantly? > > > > > >-Tim > > > > > > > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
