Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0 (2.2 plugin)
    • Fix Version/s: 2.3.1
    • Component/s: JUnit 3.x support
    • Labels:
      None
    • Environment:
      maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, surefire 2.0, gentoo linux x86
    • Patch Submitted:
      Yes
    • Number of attachments :
      4

      Description

      Surefire incorrectly interprets classpath ordering.
      Steps to reproduce:
      1. unzip my-app.zip - it's a simple mvn project created with
      mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app
      and lightly patched
      2. mvn test
      in my case, it prints out
      jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties
      jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties
      which is incorrect. log4j.properties is located both in jxta.jar and src/test/resources, but I think that src/test/resources takes precedence over jxta. This ordering is set correctly in surefire36745tmp file I think, but surefire seems to ignore the ordering.

        Issue Links

          Activity

          Hide
          Paul Gier added a comment -

          The classes directory is put in front of the test-classes directory in MavenProject.java.
          I created another issue under maven-project to fix this.

          Show
          Paul Gier added a comment - The classes directory is put in front of the test-classes directory in MavenProject.java. I created another issue under maven-project to fix this.
          Hide
          Paul Gier added a comment -

          The issue can be seen mainly when the fork mode is set to never. Because if the surefire plugin forks, then the ordering gets rearranged similar to what Barrett described. However, I think this is caused by loading the paths into the properties object and then using an enumeration to iterate through them. The Properties object doesn't retain the order of the loaded props, so they really could come out in any order, not just the sorted order that is shown above.

          So I think that Barrett's approach is the right one. The classpath elements really need to be sorted after they are loaded from properties file. Hopefully someone will apply his patch or something similar to it soon

          Show
          Paul Gier added a comment - The issue can be seen mainly when the fork mode is set to never. Because if the surefire plugin forks, then the ordering gets rearranged similar to what Barrett described. However, I think this is caused by loading the paths into the properties object and then using an enumeration to iterate through them. The Properties object doesn't retain the order of the loaded props, so they really could come out in any order, not just the sorted order that is shown above. So I think that Barrett's approach is the right one. The classpath elements really need to be sorted after they are loaded from properties file. Hopefully someone will apply his patch or something similar to it soon
          Hide
          Paul Gier added a comment -

          Attaching a slightly cleaned up patch.

          Show
          Paul Gier added a comment - Attaching a slightly cleaned up patch.
          Hide
          Brett Porter added a comment -

          will review patch for 2.3.1

          Show
          Brett Porter added a comment - will review patch for 2.3.1
          Hide
          Brett Porter added a comment -

          applied, thanks

          Show
          Brett Porter added a comment - applied, thanks

            People

            • Assignee:
              Brett Porter
              Reporter:
              Martin Vysny
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: