Maven Surefire
  1. Maven Surefire
  2. SUREFIRE-121

System properties set on the command line get clobbered

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0 (2.2 plugin)
    • Fix Version/s: 2.6
    • Component/s: None
    • Labels:
      None
    • Environment:
      Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0
    • Number of attachments :
      1

      Description

      Some system properties get clobbered if you set them on the command line. For example,

      mvn clean test -Dtest=LoginTest -Dselenium.user=test32

      The 'test' system property will work, but the 'selenium.user' property will be null at runtime. I have tried:

      • hard coding the system property in the unit test, this worked fine.
      • setting the system properties in the pom file, this worked fine also.
      • tried an older version of the surefire plugin, this worked fine.

        Issue Links

          Activity

          Hide
          Stefano Fornari added a comment -

          Adding a simple project to reproduce the issue

          Show
          Stefano Fornari added a comment - Adding a simple project to reproduce the issue
          Hide
          sridhar added a comment - - edited

          Any workaround on this issue? i'm encountering same problem and at a loss of how to proceed.

          if i use 2.4.2, then i get

          java.lang.ClassNotFoundException: org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite

          Show
          sridhar added a comment - - edited Any workaround on this issue? i'm encountering same problem and at a loss of how to proceed. if i use 2.4.2, then i get java.lang.ClassNotFoundException: org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite
          Hide
          Frédéric Camblor added a comment -

          +1
          In a Test framework we've made, we're executing tests in eclipse by building maven.

          The test framework allow to pass system properties in order to "filter" executed test by "categories"
          Example :
          mvn test -Dtest.categories=non-regression
          (that will only execute non regression tests during maven test phase "a la" TestNG)

          Since maven 2.0.10 (which aligned with surfire 2.4.3) we no longer can use this functionnality ...

          Only workarounds for us is either :

          • keep maven 2.0.9 (but this is crappy !!)
          • use explicitely surefire 2.4.2 (impacts on most of our poms)
          • define hacks in the poms, such as :
            <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>$ {surefire.version}

            </version>
            <configuration>
            <systemProperties>
            <test.categories>$

            {test.categories}

            </test.categories>
            </systemProperties>
            </configuration>
            </plugin>
            (impacts on most of our poms, too)

          This is really crappy !!!

          Show
          Frédéric Camblor added a comment - +1 In a Test framework we've made, we're executing tests in eclipse by building maven. The test framework allow to pass system properties in order to "filter" executed test by "categories" Example : mvn test -Dtest.categories=non-regression (that will only execute non regression tests during maven test phase "a la" TestNG) Since maven 2.0.10 (which aligned with surfire 2.4.3) we no longer can use this functionnality ... Only workarounds for us is either : keep maven 2.0.9 (but this is crappy !!) use explicitely surefire 2.4.2 (impacts on most of our poms) define hacks in the poms, such as : <plugin> <artifactId>maven-surefire-plugin</artifactId> <version>$ {surefire.version} </version> <configuration> <systemProperties> <test.categories>$ {test.categories} </test.categories> </systemProperties> </configuration> </plugin> (impacts on most of our poms, too) This is really crappy !!!
          Hide
          Jose Negreira added a comment -

          Hi all, I've tried a cleaner workaround:

          This was the not working property:
          mvn test -Dtest=myTest -DserverUrl=foobar
          serverUrl comes null.

          And this is the working property using -DargLine:
          mvn test -Dtest=myTest -DargLine=-DsomeUrl=foobar
          serverUrl has 'foobar' value

          for more than 1 parameter:
          mvn test -Dtest=myTest -DargLine="-DsomeUrl=foobar -DotherParam=otherValue"

          Credits for this go to Maximiliano Vazquez. (Thanks!)

          HTH

          Jose Negreira

          Show
          Jose Negreira added a comment - Hi all, I've tried a cleaner workaround: This was the not working property: mvn test -Dtest=myTest -DserverUrl=foobar serverUrl comes null. And this is the working property using -DargLine: mvn test -Dtest=myTest -DargLine=-DsomeUrl=foobar serverUrl has 'foobar' value for more than 1 parameter: mvn test -Dtest=myTest -DargLine="-DsomeUrl=foobar -DotherParam=otherValue" Credits for this go to Maximiliano Vazquez. (Thanks!) HTH Jose Negreira
          Hide
          Benjamin Bentmann added a comment -

          Fixed in r981279 by selectively propagating only those system properties to the tests that have been set by the user on the Maven command line via -Dkey=value, system props passed directly into the JVM via MAVEN_OPTS are not forwarded to the tests.

          For this actually to work, Maven 2.1.0 or newer is required. For Maven 2.0.x, no system properties are propagated as in previous plugin versions and a warning is emitted.

          Show
          Benjamin Bentmann added a comment - Fixed in r981279 by selectively propagating only those system properties to the tests that have been set by the user on the Maven command line via -Dkey=value , system props passed directly into the JVM via MAVEN_OPTS are not forwarded to the tests. For this actually to work, Maven 2.1.0 or newer is required. For Maven 2.0.x, no system properties are propagated as in previous plugin versions and a warning is emitted.

            People

            • Assignee:
              Benjamin Bentmann
              Reporter:
              Brenton Leanhardt
            • Votes:
              22 Vote for this issue
              Watchers:
              27 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: