Maven
  1. Maven
  2. MNG-1378

Make dependencies of test-jars transitive

    Details

      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

      1. mng1378.tar.gz
        2 kB
        Lukas JOSEFIK

        Issue Links

          Activity

          Hide
          Carlos Sanchez added a comment -

          Set a better title. The problem here is that by design test dependencies are not transitive

          Show
          Carlos Sanchez added a comment - Set a better title. The problem here is that by design test dependencies are not transitive
          Hide
          Kenney Westerhof added a comment -

          changed the title as 'Make test dependencies transitive' is incorrect. Test dependencies
          are dependencies with scope test. test-jar dependencies are something totally different,
          and they can have scope compile.

          Show
          Kenney Westerhof added a comment - changed the title as 'Make test dependencies transitive' is incorrect. Test dependencies are dependencies with scope test. test-jar dependencies are something totally different, and they can have scope compile.
          Hide
          Lukas Theussl added a comment -

          Attaching a simple test project as I just came across this. It doesn't cover all possible manifestations but is the simplest self-contained example that I could come up with. Running test in impl fails, uncommenting the util dependency (non test-jar) in impl's pom makes it pass. In practice I guess this bug is often masked by the fact that you also have a dependency on the corresponding main jar anyway.

          Show
          Lukas Theussl added a comment - Attaching a simple test project as I just came across this. It doesn't cover all possible manifestations but is the simplest self-contained example that I could come up with. Running test in impl fails, uncommenting the util dependency (non test-jar) in impl's pom makes it pass. In practice I guess this bug is often masked by the fact that you also have a dependency on the corresponding main jar anyway.
          Hide
          Ittay Dror added a comment -

          is there a workaround? right now this means I have to copy&paste all test dependencies. (I can't separate to an independent module since test-jar depends on classes in the module and the module's test depend on the test-jar)

          Show
          Ittay Dror added a comment - is there a workaround? right now this means I have to copy&paste all test dependencies. (I can't separate to an independent module since test-jar depends on classes in the module and the module's test depend on the test-jar)
          Hide
          Didier Loiseau added a comment -

          Any progress on this issue? As of 2.2.1 it does not seem to be fixed …
          I have exactly the same use case than Ittay and this is very annoying as the test-jar dependencies evolve.

          Show
          Didier Loiseau added a comment - Any progress on this issue? As of 2.2.1 it does not seem to be fixed … I have exactly the same use case than Ittay and this is very annoying as the test-jar dependencies evolve.
          Hide
          William Ghelfi added a comment -

          I have a (not so) slightly different use case and really would like to see this issue fixed...

          Show
          William Ghelfi added a comment - I have a (not so) slightly different use case and really would like to see this issue fixed...
          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
          Josh Chaitin-Pollak added a comment -

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

          Show
          Josh Chaitin-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.
          Hide
          Anders Kristian Andersen added a comment -

          In my eyes tests are not public by any way
          It is interfaces and implementation that makes an artifact

          Therefore extending test cases is not something I would do.
          Not only should you make correct interfaces and implementation, now you also need to consider making tests so they can be extended ..
          This pattern would add complexity to an artifact.

          I find the system is designed correct as it is !
          -1

          Show
          Anders Kristian Andersen added a comment - In my eyes tests are not public by any way It is interfaces and implementation that makes an artifact Therefore extending test cases is not something I would do. Not only should you make correct interfaces and implementation, now you also need to consider making tests so they can be extended .. This pattern would add complexity to an artifact. I find the system is designed correct as it is ! -1
          Hide
          Didier Loiseau added a comment -

          Then I guess dependencies on test-jars should be completely disallowed. If your tests depend on some test-jar, and you don't have the dependencies of that test-jar, it is well possible that your tests cannot compile at all!

          It is not just a question of extending test cases, it could also be a question of reusing some other classes of the test-jar.

          For example, suppose you have module X and module Y which depends on X. In the test classes of module X, you implement a TestUtil class which relies on some other class of X's main classpath and on some class from a test-scoped dependency. Of course, the tests of X depend on TestUtil.

          Now, in the tests of module Y, you would like to reuse TestUtil. You thus need to declare a test-scoped dependency on X's test-jar. But for the moment you also have to redeclare all the test-scoped dependencies of X in order to use that class. And you cannot move that class somewhere else, due to its dependencies.

          Show
          Didier Loiseau added a comment - Then I guess dependencies on test-jars should be completely disallowed. If your tests depend on some test-jar, and you don't have the dependencies of that test-jar, it is well possible that your tests cannot compile at all! It is not just a question of extending test cases, it could also be a question of reusing some other classes of the test-jar. For example, suppose you have module X and module Y which depends on X. In the test classes of module X, you implement a TestUtil class which relies on some other class of X's main classpath and on some class from a test-scoped dependency. Of course, the tests of X depend on TestUtil . Now, in the tests of module Y, you would like to reuse TestUtil . You thus need to declare a test-scoped dependency on X's test-jar. But for the moment you also have to redeclare all the test-scoped dependencies of X in order to use that class. And you cannot move that class somewhere else, due to its dependencies.
          Hide
          Peter Ansell added a comment -

          One alternative if you need to depend on a testsuite that is published by a different module to ensure that the testsuite is published as a "jar", not a "test-jar", and it is pulled into "test" scope in the local module, with all of its dependencies. I have used this "testsuite-module" + "testrunner-module" pattern successfully in the past to publish both concrete and abstract testclasses, although generally only for compliance tests where a specific interface or protocol is being tested based on a well known specification.

          Show
          Peter Ansell added a comment - One alternative if you need to depend on a testsuite that is published by a different module to ensure that the testsuite is published as a "jar", not a "test-jar", and it is pulled into "test" scope in the local module, with all of its dependencies. I have used this "testsuite-module" + "testrunner-module" pattern successfully in the past to publish both concrete and abstract testclasses, although generally only for compliance tests where a specific interface or protocol is being tested based on a well known specification.
          Hide
          Reto Gmuer added a comment -

          I agree with the last three comments. Write a test-utils artifact which can then be a test-scoped dependency of sub1 and sub2, test-utils will have commons-lang as a normal (compile-time) dependency.

          Show
          Reto Gmuer added a comment - I agree with the last three comments. Write a test-utils artifact which can then be a test-scoped dependency of sub1 and sub2, test-utils will have commons-lang as a normal (compile-time) dependency.

            People

            • Assignee:
              Unassigned
              Reporter:
              Mark Hobson
            • Votes:
              57 Vote for this issue
              Watchers:
              61 Start watching this issue

              Dates

              • Created:
                Updated:

                Development