# Make dependencies of test-jars transitive

## Details

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.0
• Fix Version/s:
• Component/s:
• Labels:
None
• Complexity:
Intermediate
• Number of attachments :
1

## Description

test-jar transitive dependencies are calculated as per compile scope rather than test scope.

The situation is demonstrated nicely in it0077:

• module sub1 has a test-scoped dependency of commons-lang
• module sub2 has a test-scoped dependency of sub1 test-jar

sub2 tests should inherit the commons-lang transitive dependency. For example:

Index: maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
===================================================================
— maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (revision
328307)
+++ maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java (working
copy)
@@ -1,6 +1,7 @@
package org.apache.maven.it0077;

import junit.framework.TestCase;
+import org.apache.commons.lang.BooleanUtils;

public class PersonTwoTest
extends PersonTest

Results in:

[INFO] ----------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ----------------------------------------------------------------------------
[INFO] Compilation failure

c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31]
package org.apache.commons.lang does not exist

## Attachments

1. mng1378.tar.gz
2 kB
Lukas Theussl

## Activity

Hide
Alex Heneveld added a comment -

+1

Naively I expected that a dependency which is both test-scoped and test-jar-classified would pull in test-scoped transitive dependencies, ie given

proj1 pom:
<dependency>
<artifactId>support</artifactId>
<scope>test</scope>
</dependency>

proj2 pom:
<dependency>
<artifactId>proj1</artifactId>
<classifer>test-jar</classifier>
<scope>test</scope>
</dependency>


Like others I'd like proj2 to see support without having to explicitly re-list it.

If I haven't declared classifier test-jar then it's fair enough not to pull in transitive test-scoped dependencies. I guess the problem is that classifier namespace isn't as formalised as scopes, and making dependency resolution itself dependent on the classifier name could get complicated?

Would a new tag <importScope>test</importScope> be a good solution?

(Although a part of me worries we this starts down a slippery slope, next wanting to introduce test-runtime and test-compile scopes...)

Show
Alex Heneveld added a comment - +1 Naively I expected that a dependency which is both test-scoped and test-jar-classified would pull in test-scoped transitive dependencies, ie given proj1 pom: <dependency> <artifactId>support</artifactId> <scope>test</scope> </dependency> proj2 pom: <dependency> <artifactId>proj1</artifactId> <classifer>test-jar</classifier> <scope>test</scope> </dependency> Like others I'd like proj2 to see support without having to explicitly re-list it. If I haven't declared classifier test-jar then it's fair enough not to pull in transitive test-scoped dependencies. I guess the problem is that classifier namespace isn't as formalised as scopes, and making dependency resolution itself dependent on the classifier name could get complicated? Would a new tag <importScope>test</importScope> be a good solution? (Although a part of me worries we this starts down a slippery slope, next wanting to introduce test-runtime and test-compile scopes...)
Hide
Tomasz Szuba added a comment -

What is the status of this issue?
Is it even considered to implement this feature?

Show
Tomasz Szuba added a comment - What is the status of this issue? Is it even considered to implement this feature?
Hide
Joshua Pollak added a comment -

I'm amazed this issue has been open 7 years, it seems so basic.

Show
Joshua Pollak added a comment - I'm amazed this issue has been open 7 years, it seems so basic.
Hide
Karl M. Davis added a comment -

For those still waiting on this, I recommend adopting the OSGi approach: separate test-only modules/projects. It's adds noise to the project structure, but is a cleaner separation. It has the added advantage of de-cluttering your project POMs and working around this issue.

Show
Karl M. Davis added a comment - For those still waiting on this, I recommend adopting the OSGi approach: separate test-only modules/projects. It's adds noise to the project structure, but is a cleaner separation. It has the added advantage of de-cluttering your project POMs and working around this issue.
Hide
Hugo Garza added a comment -

I was able to solve this by moving my test dependencies into the parent POM that both projects share, but this isn't possible in every case.

I guess the only thing I can do for now is to cast my vote for hopefully getting this feature implemented. I just learned about test-jar and was excited that it would just work but then I got my ClassNotFoundException and realized it was because of my missing transitive test dependencies.

Show
Hugo Garza added a comment - I was able to solve this by moving my test dependencies into the parent POM that both projects share, but this isn't possible in every case. I guess the only thing I can do for now is to cast my vote for hopefully getting this feature implemented. I just learned about test-jar and was excited that it would just work but then I got my ClassNotFoundException and realized it was because of my missing transitive test dependencies.

## People

• Assignee:
Unassigned
Reporter:
Mark Hobson