Project-A provides some functionality (let's say it's a Ledger Aspect), and as part of the project's test code, it contains a mocked out persistence layer that makes use of a Ledger Aspect Test Harness to provide full test coverage. Project-A's pom snippet will look like this and won't have anything noteworthy there.
<project> <artifactId>projecta</artifactId> <groupId>myProjects</groupId> <version>1</version> <name>Project A</name> </project>
Project-B makes use of the Ledger Aspect, and as part of the developing team's process, they want to write a unit test that makes use of the Ledger Aspect Test Harness to test that Project-B can actually integrate with Project-A. We start out with a "naïve" pom to capture the dependencies.
<project> <artifactId>projectb</artifactId> <name>Project B</name> <dependencies> <dependency> <artifactId>projecta</artifactId> <groupId>myProjects</groupId> <version>1</version> </dependency> </dependencies> </project>
The problem we'll see is that the Ledger Aspect Test Harness is part of Project-A's test code, and will therefore not be part of the artifact build, so when we run our maven test goal on Project-B, we are given a build failure on our test classes.
There are two steps to solving this problem. To get it to work, you have to follow them exactly. First, tell Project-A to build its test classes, and deploy them in a test jar.
<build> <plugins> <plugin> <artifactId>maven-jar-plugin</artifactId> <executions> <execution> <phase>package</phase> <goals> <goal>test-jar</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
Once you include this snippet in Project-A's pom, you will see the projecta-1-tests.jar artifact appear in your repository (on install or deploy). The "tests" portion of the artifact name is a hidden classifier that is automatically assigned by the maven-jar-plugin. Do not try and specify a classifier - this is done for you behind the scenes.
Next, add a new dependency to Project-B's pom, like this. Note that the scope is "test" (singular) and the classifier is "tests" (plural). This is because "test" is a legitimate scope that Maven provides, whereas "tests" is simply an ad-hoc classifier that the maven-jar-plugin creates behind the scenes.
<dependency> <artifactId>projecta</artifactId> <groupId>myProjects</groupId> <version>1</version> <classifier>tests</classifier> <scope>test</scope> </dependency>
This allows Project-B to have its tests (but not its main code) compile against the test code from Project-A. In this example, Project-B's main code does depend on Project-A's main code, but it so happens that Project-B's test code has an additional dependency on Project-A's test code.
As a side note... Another way to point Project-A's dependency to the test jar is by specifying the type as "test-jar". This is the way recommended by the "Guide to using attached tests" at http://maven.apache.org/guides/mini/guide-attached-tests.html
One problem with this approach is that while the "tests" classifier magically appears on the artifact name, the "test-jar" type doesn't appear anywhere except in Project-A's dependency. I do not know of any reasons why it is preferrable to use type over classifierJust follow http://maven.apache.org/guides/mini/guide-attached-tests.html.
It doesn't explain why you should use
but one reason I can think of is that by using the type tag, you reduce the possible confusion with using type of jar and classifier of tests.