Integration test.
If classes are moved to test folder and dependency set as test scope it works fine, using the jar from repo
If trying to use in compile scope it references ../child1/target/classes twice in the compiler classpath

Brian, it works if you use test-jar in a test scope, which is the usual case. Your main classes shuldn't depend on test classes from other modules

Yes, I realize this is an unusual case. The code is something we are working to fix, but it was working until I moved it into a common parent in preparation for some other stuff. It seems by extension this would be a problem for other dependencies that use classifiers.

I believe this is related to MWAR-7 and MOJO-286

We have the normal case, but it won't work unless we before an install first.

We have the normal case, but it won't work unless we do an install first.

So mvn clean install on the project will run the tests correctly.
But mvn clean test won't because the test-jar dependency won't resolve.

Tested with 2.0.6, this no longer occurs. It's fixed by MNG-2877

This issue still occurs for me. Tested with maven 2.0.6 and 2.0.7. I still have to run a install first.

We're also running into this problem, which is that:

• We have project A with common test classes in src/main/test
• Project A creates a test jar
• Project B depends on project A's test jar in compile scope
• Project B builds fine if built on it's own, but fails when in a reactor build with project A.

I know we shouldn't have a dependency from the main code of B to a test artifact of project A, but it would make my job considerably easier if this "just worked", or even if it also failed when only building project B.

This should be fixed. If you can reproduce, please make an IT test and attach. Instructions for an IT are here: http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test

Attaching mng-2045-ittest.zip, which contains an integration test reproducing the problem. Well, at least "on-my-machine" anyway.

Tested with maven 2.0.7.

will try out the IT, thanks.

I'm having the same issue where we have one module whose main classes depend on test classes from another module. I'm attaching a simple fix for this where the artifact type is checked (test-jar) when adding the path.

This patch has a slight enhancement over the first one I submitted. The problem with the first, is that if "clean compile" is run in a multi-module project, then the test-classes directory does not exist. So this patch checks for the existence of the test output directory. And if it does not exist, it falls back to the repository.

Patch and core it applied thanks to all that contributed. The IT test passes now.

Brian,

I find both sample projects (it1021.tar.gz and sample.zip) not working in 2.0.8). Can you comment on this, please? Thanks

Tomas

this was fixed in 2.0.8 - sample.zip, it1021.tar.gz and the integration all test with it.

Please open a new issue with more specifics if you are still seeing the problem.

I don't think this bug is fixed.

If I download sample.zip and run 'mvn test-compile', I get the following:

jpollak@Challenger:~/src$ cd sample/
jpollak@Challenger:~/src/sample$ ls
pom.xml sample-jar sample-jar-user
jpollak@Challenger:~/src/sample$ mvn test-compile
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - sample-project:sample-parent:pom:SNAPSHOT
[INFO] Maven Quick Start Archetype
[INFO] Maven Quick Start Archetype
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - sample-project:sample-parent:pom:SNAPSHOT
[INFO] task-segment: [test-compile]
[INFO] ------------------------------------------------------------------------
[INFO] No goals needed for project - skipping
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Quick Start Archetype
[INFO] task-segment: [test-compile]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Quick Start Archetype
[INFO] task-segment: [test-compile]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) sample-project:sample-jar:test-jar:tests:SNAPSHOT

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=sample-project -DartifactId=sample-jar -Dversion=SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=sample-project -DartifactId=sample-jar -Dversion=SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

Path to dependency:
1) sample-project:sample-jar-user:jar:SNAPSHOT
2) sample-project:sample-jar:test-jar:tests:SNAPSHOT

----------
1 required artifact is missing.

for artifact:
sample-project:sample-jar-user:jar:SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Tue Apr 29 18:55:27 EDT 2008
[INFO] Final Memory: 3M/6M
[INFO] ------------------------------------------------------------------------

I am seeing the same behavior with maven 2.0.9 when trying to build logback. See
http://svn.qos.ch/viewvc/logback/trunk/ if you would like to check out the project.

In this particular case, logback-classic depends on logback-core as follows:

<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<scope>compile</scope>
</dependency>

<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>

For a pristine installation, 'mvn package' fails with

===================
Missing:
----------
1) ch.qos.logback:logback-core:jar:tests:0.9.10

Try downloading the file manually from the project website.
[snip]

Path to dependency:
1) ch.qos.logback:logback-classic:jar:0.9.10
2) ch.qos.logback:logback-core:jar:tests:0.9.10

===================

whereas 'mvn install' works fine.

The SLF4J project which I maintain suffers from the same problem. See http://svn.slf4j.org/repos/slf4j/trunk/ is you wish to check out SLF4J.

For whatever it is worth, you may define the dependency as

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <type>test-jar</type>
    <scope>test</scope>
</dependency>

at least such a declaration works in quite some of our projects.

Thank you Joerg. The change you suggested worked beautifully.

The documentation has been fixed in r709688. Left to discussion is whether the <classifier>tests</classifier> approach should also be supported.

could this be considered fixed in 2.0.10 and a new issue opened for the classifier approach?

The issue that was originally reported here, i.e. a bad compile class path when depending on a test JAR and running the install phase of a reactor build, was fixed in 2.0.8. Other issues like only running the test phase (MNG-3043) or the proper way to declare a test JAR dependency (MNG-4056) are addressed by the referenced JIRA tickets.

I have attemted Joerg's suggestion, and I am afraid that I am experiencing the same problem with maven 2.1.0. So it does not appear that this issue has been fixed for multi-module projects.