ModeShape
  1. ModeShape
  2. MODE-1140

Maven build is not running older JUnit 3 unit tests (e.g., the TCK unit tests)

    Details

    • Estimated Difficulty:
      Low
    • Similar Issues:
      Show 10 results 

      Description

      When we changed to use Maven 3 (see MODE-1096), we started explicitly specifying the versions for each of the Maven plugins, including the Surefire plugin that runs our unit tests. When we did this, we chose to use the latest version of Surefire (2.7.1), even though 2.7 had a severe change in behavior with respect to determining which unit test classes should be run. For details, see SUREFIRE-482, the release notes for Surefire 4.7, and the Surefire JUnit usage page.

      Unfortunately, when I did the initial conversion to Maven 3, I didn't see the supposed warning message about running Maven with the "-Dsurefire.junit4.upgradecheck" argument, and therefore missed the fact that we were no longer running the TCK tests.

        Activity

        Hide
        Randall Hauch
        added a comment -

        According to the Surefire JUnit usage page, it is possible to explicitly choose which JUnit provider to use. The latest ("surefire-junit47") is what implements the new crappy determination of which test classes should be run, so we can instead manually specify "surefire-junit-4" to get the older behavior. (Normally, Surefire determines which provider to use by looking at the classpath, so manually specifying the provider also is a workaround when the wrong provider is specified.)

        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.8</version>
            <dependencies>
              <dependency>
                <groupId>org.apache.maven.surefire</groupId>
                <!-- Manually specify the JUnit provider -->
                <artifactId>surefire-junit4</artifactId>
                <version>2.8</version>
              </dependency>
            </dependencies>
            ...
        </plugin>
        

        Unfortunately, that causes a failure on these two modules that don't have unit tests:

        • modeshape-jcr-api (which just has interfaces)
        • modeshape-jbossas-console (which doesn't have unit tests! WTF?)

        Simply adding the JUnit dependency to these modules fixes the problem.

        (It's also possible to revert back to using Surefire 2.6, which is the last version before 2.7. But I'd rather use the latest version, which is quite a bit smaller than 2.6.)

        Show
        Randall Hauch
        added a comment - According to the Surefire JUnit usage page , it is possible to explicitly choose which JUnit provider to use. The latest ("surefire-junit47") is what implements the new crappy determination of which test classes should be run, so we can instead manually specify "surefire-junit-4" to get the older behavior. (Normally, Surefire determines which provider to use by looking at the classpath, so manually specifying the provider also is a workaround when the wrong provider is specified.) <plugin> <artifactId> maven-surefire-plugin </artifactId> <version> 2.8 </version> <dependencies> <dependency> <groupId> org.apache.maven.surefire </groupId> <!-- Manually specify the JUnit provider --> <artifactId> surefire-junit4 </artifactId> <version> 2.8 </version> </dependency> </dependencies> ... </plugin> Unfortunately, that causes a failure on these two modules that don't have unit tests: modeshape-jcr-api (which just has interfaces) modeshape-jbossas-console (which doesn't have unit tests! WTF?) Simply adding the JUnit dependency to these modules fixes the problem. (It's also possible to revert back to using Surefire 2.6, which is the last version before 2.7. But I'd rather use the latest version, which is quite a bit smaller than 2.6.)
        Hide
        Randall Hauch
        added a comment -

        The proposed changes appear to work well. Marking as 'resolved'.

        Show
        Randall Hauch
        added a comment - The proposed changes appear to work well. Marking as 'resolved'.

          People

          • Assignee:
            Randall Hauch
            Reporter:
            Randall Hauch
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: