Maven
  1. Maven
  2. MNG-3118

Test-classes should come before classes in the classpath

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.7
    • Fix Version/s: 2.0.8, 3.0-alpha-1
    • Component/s: General
    • Labels:
      None
    • Patch Submitted:
      Yes
    • Number of attachments :
      1

      Description

      Currently maven-project creates the test classpath in the order: classes, tests-classes, dependencies.
      It would be better if test-classes came first because sometimes it is useful for a test class to replace a main class during testing. The opposite case is not normally true (i.e. one would not want to override a test class with one of the main classes).

        Issue Links

          Activity

          Hide
          Paul Gier added a comment -

          Simple patch that reverses the classpath ordering of classes and test-classes.

          Show
          Paul Gier added a comment - Simple patch that reverses the classpath ordering of classes and test-classes.
          Hide
          Brett Porter added a comment -

          Makes sense. One thing I want to review is how this is used - might be better to externalise this from maven-project into surefire.

          Show
          Brett Porter added a comment - Makes sense. One thing I want to review is how this is used - might be better to externalise this from maven-project into surefire.
          Hide
          Kenney Westerhof added a comment -

          fixed in trunk at r559042 and 2.0.x branch at 559045

          Show
          Kenney Westerhof added a comment - fixed in trunk at r559042 and 2.0.x branch at 559045
          Hide
          Henri Tremblay added a comment -

          Hi, are you sure of the fix? Because I'm using maven 2.0.7 and test-classes was first in the classpath for almost a year now. I just tried with maven 2.0.8, doesn't work anymore. classes path seems to be first.

          Is there a workaround?

          Because this ordering is indeed extremely useful.

          Show
          Henri Tremblay added a comment - Hi, are you sure of the fix? Because I'm using maven 2.0.7 and test-classes was first in the classpath for almost a year now. I just tried with maven 2.0.8, doesn't work anymore. classes path seems to be first. Is there a workaround? Because this ordering is indeed extremely useful.
          Hide
          Andreas Bjärlestam added a comment -

          Hi, I have a similar problem. I need to mock a dependency library in my maven project, but maven puts the dependencies before the test-classes in the classpath. I see the same behaviour in both 2.0.7 and 2.0.8.

          Show
          Andreas Bjärlestam added a comment - Hi, I have a similar problem. I need to mock a dependency library in my maven project, but maven puts the dependencies before the test-classes in the classpath. I see the same behaviour in both 2.0.7 and 2.0.8.
          Hide
          Benjamin Bentmann added a comment -

          Henri, Andreas, I think you are suffering from problems with Surefire 2.3. The MavenProject.getTestClasspathElements() in Maven 2.0.8 now properly puts test-classes before classes (see code in svn or Maven's debug output when using -X). However, Surefire 2.3 itself causes a reordering of the class path in its SurefireBooter as reported in SUREFIRE-61. This issue has been marked as fixed and I just noticed a svn tag for Surefire 2.3.1 has been created. So, it might be just a few days until a working Surefire version is released and this problem is entirely solved.

          Show
          Benjamin Bentmann added a comment - Henri, Andreas, I think you are suffering from problems with Surefire 2.3. The MavenProject.getTestClasspathElements() in Maven 2.0.8 now properly puts test-classes before classes (see code in svn or Maven's debug output when using -X). However, Surefire 2.3 itself causes a reordering of the class path in its SurefireBooter as reported in SUREFIRE-61 . This issue has been marked as fixed and I just noticed a svn tag for Surefire 2.3.1 has been created. So, it might be just a few days until a working Surefire version is released and this problem is entirely solved.
          Hide
          KlaasJan Elzinga added a comment -

          I am seeing the following:

          in mvn 2.0.7 the test resources are put before the main-resources (src/main/resources) as expected.
          in mvn 2.0.8 the main resources are put before the test-resources (src/test/resources).

          Is this correct? I wouldnt expect it to happen. This caused my build to fail (connections made to a real environment ie stubs).

          Is this related to this 'feature'?

          Show
          KlaasJan Elzinga added a comment - I am seeing the following: in mvn 2.0.7 the test resources are put before the main-resources (src/main/resources) as expected. in mvn 2.0.8 the main resources are put before the test-resources (src/test/resources). Is this correct? I wouldnt expect it to happen. This caused my build to fail (connections made to a real environment ie stubs). Is this related to this 'feature'?
          Hide
          Henri Tremblay added a comment -

          KlassJan, read the other comments. It seems the problem is coming from Surefire. So you can wait for the fix to be released or build the plugin yourself (if you do so, I would be interested in knowing if it worked)

          Show
          Henri Tremblay added a comment - KlassJan, read the other comments. It seems the problem is coming from Surefire. So you can wait for the fix to be released or build the plugin yourself (if you do so, I would be interested in knowing if it worked)
          Hide
          KlaasJan Elzinga added a comment -

          Henri,

          Thanks, I was wondering if it were just the classes or the classes and the resources. So its both, I'll just revert to 2.0.7 and wait for the surefire.

          Show
          KlaasJan Elzinga added a comment - Henri, Thanks, I was wondering if it were just the classes or the classes and the resources. So its both, I'll just revert to 2.0.7 and wait for the surefire.
          Hide
          KlaasJan Elzinga added a comment -

          The surefire plugin was release today, but now all my tests fail on the 2.0.7. Isnt this a very serious regression?

          In 2.0.7 my builds fail cause the surefire plugin is to new, 2.0.8 is not yet feasable ..... This mirroring of bugs in plugins is really really a very good idea. And than to solve it in a patch version.

          I quit with maven.

          Show
          KlaasJan Elzinga added a comment - The surefire plugin was release today, but now all my tests fail on the 2.0.7. Isnt this a very serious regression? In 2.0.7 my builds fail cause the surefire plugin is to new, 2.0.8 is not yet feasable ..... This mirroring of bugs in plugins is really really a very good idea. And than to solve it in a patch version. I quit with maven.
          Hide
          Benjamin Bentmann added a comment -

          Well, how should Maven have kept backward compatibility here? There can only be one class path order.

          If Surefire 2.3.1 is not usable for you (I feel happy with it and Maven 2.0.8), you can lock your POM to Surefire 2.3 by explicitly specifying <version>2.3</version> in the corresponding <plugin> element.

          Show
          Benjamin Bentmann added a comment - Well, how should Maven have kept backward compatibility here? There can only be one class path order. If Surefire 2.3.1 is not usable for you (I feel happy with it and Maven 2.0.8), you can lock your POM to Surefire 2.3 by explicitly specifying <version>2.3</version> in the corresponding <plugin> element.
          Hide
          KlaasJan Elzinga added a comment -

          It just didn't feel like a patch version change. The fact that my build failed first with 2.0.8 and a week later with 2.0.7 doesn't feel right.

          Backwards compatibility could be accomplished by mvn querying the surefire plugin version and construct the path with respect to that version. FYI, I was using mvn in an environment where upgrades are not allways possible/easy (...and all the dvl'ers had to upgrade), I know how to work around it, which meant a code change or an upgrade.

          In the end I advised everyone to upgrade to 2.0.8. I'll stop commenting on this issue since this is not really the place for it anyway.

          Thanks for the reaction though.

          Show
          KlaasJan Elzinga added a comment - It just didn't feel like a patch version change. The fact that my build failed first with 2.0.8 and a week later with 2.0.7 doesn't feel right. Backwards compatibility could be accomplished by mvn querying the surefire plugin version and construct the path with respect to that version. FYI, I was using mvn in an environment where upgrades are not allways possible/easy (...and all the dvl'ers had to upgrade), I know how to work around it, which meant a code change or an upgrade. In the end I advised everyone to upgrade to 2.0.8. I'll stop commenting on this issue since this is not really the place for it anyway. Thanks for the reaction though.
          Hide
          Ceki Gulcu added a comment -

          In my 20 months experience with Maven, the test-classes always came before "classes". This is a feature that I heavily rely on. Could you please kindly document this behavior as part of the Maven/Surefire contract, so that the re-ordering problem does not reoccur?

          Many thanks in advance,

          Show
          Ceki Gulcu added a comment - In my 20 months experience with Maven, the test-classes always came before "classes". This is a feature that I heavily rely on. Could you please kindly document this behavior as part of the Maven/Surefire contract, so that the re-ordering problem does not reoccur? Many thanks in advance,
          Hide
          Juan Losada added a comment -

          Same to me Ceki. Days of work lost cause this.

          Not to mention a regression issue in the surefire 2.3 with testng that only allows me to work with 2.4-SNAPSHOT

          And although I love maven my only way out is to migrate everything to ant if I don't want to lose the testing options in my C.I. machine. This just sad!!

          Show
          Juan Losada added a comment - Same to me Ceki. Days of work lost cause this. Not to mention a regression issue in the surefire 2.3 with testng that only allows me to work with 2.4-SNAPSHOT And although I love maven my only way out is to migrate everything to ant if I don't want to lose the testing options in my C.I. machine. This just sad!!
          Hide
          Benjamin Bentmann added a comment -

          While I agree that having a documentation would be nice, it does not prevent the bugs from reoccurring. What you really want are tests. Therefore, you are invited to vote for MNG-2365 and SUREFIRE-428.

          Show
          Benjamin Bentmann added a comment - While I agree that having a documentation would be nice, it does not prevent the bugs from reoccurring. What you really want are tests. Therefore, you are invited to vote for MNG-2365 and SUREFIRE-428 .

            People

            • Assignee:
              Unassigned
              Reporter:
              Paul Gier
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: