Maven
  1. Maven
  2. MNG-1378

Make dependencies of test-jars transitive

    Details

    • 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

        Issue Links

          Activity

          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 Kr. 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 Kr. 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:
              68 Vote for this issue
              Watchers:
              69 Start watching this issue

              Dates

              • Created:
                Updated: