Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »


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-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.

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.

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.

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
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 classifier.

  • No labels