System properties set on the command line get clobbered

Fixed in revision 598217.

This seriously breaks embedded usage. See this email sent to mevenide's mailing list:

It looks like, although my tests are configured to use either
forkMode=once or forkMode=perTest, Mevenide and/or the
maven-surefire-plugin in 2.4 either do not fork or (most probably) start
these new JVMs by explicitly (and incorrectly) passing all the system
properties and property values of the currently running JVM (i.e. the
JVM running the Netbeans IDE).

This means these system properties have "interesting" values when the
JUnit test code is running, like e.g.:

javax.xml.parsers.DocumentBuilderFactory=org.netbeans.core.startup.DOMFactoryImpl
javax.xml.parsers.SAXParserFactory=org.netbeans.core.startup.SAXFactoryImpl

As these NetBeans factory classes are not available from my project's
Meven test classpath, all my XML-related tests do now fail.

In addition, I get a message about a missing Logger configuration class:

Logging configuration class "org.netbeans.core.startup.TopLogging" failed
java.lang.ClassNotFoundException: org.netbeans.core.startup.TopLogging
–

MavenSession.getExecutionProperties() shall be the preferred call to System.getProperties()

I believe pushing the System.getProperties() to a forked process is wrong generally.

"java.library.path", "java.class.path" and all JVM properties will be pushed from the maven process to the forked one, possibly polluting it, especially when the forked process is to be executed with a different JVM instance.

fixed the embedded use problem.
http://svn.apache.org/viewvc?rev=613539&view=rev

This hotfix switches from using System.getProperties to using MavenSession.getExecutionProperties. MavenSession has no JavaDoc (or documentation of any kind?) so it's hard for me to tell how this hotfix works. What sort of properties get into executionProperties? What properties don't get into executionProperties?

http://maven.apache.org/ref/2.0.8/maven-core/apidocs/org/apache/maven/execution/MavenSession.html

Unfortunately most components/classes in Maven have no javadoc, MavenSession is no exception. Since the instance can be retrieved via the $

expression in mojos, it makes it part of the official APIs to me though. Other can have more insight on the status of the class..

Currently the command line maven put all System.getProperties() there plus any props that were added on the command line.
Embedders can choose to provide same set or limit it. (eg. in my case I now filter out any netbeans-related properties in System.getproperties() list to prevent XML parser failures)

Deliberately broken in revision 652773 to fix SUREFIRE-491.

Just Confirming... with maven 2.0.9 and 2.0.10-RC11, properties set on the command line are not passed to unit tests run by surefire 2.4.3. v2.4.2 passes the system properties.

For example:

With v2.4.2, System.getProperty("jdbc.host") returns 192.168.2.100. With v.2.4.3 it returns null.

We rely on this behavior in unit tests frequently, sometime via System.getProperty() and other times indirectly through the use of Spring's PropertyPlaceholderConfigurer in SYSTEM_PROPERTIES_MODE_OVERRIDEmode.

Is the plan to revert back to the 2.4.2 behavior?

I'm also interested in what happens in this bug.

2 potential solutions.

1. just toggle between the two behaviors based on a <useSystemProperties>true</useSystemProperties> flag
2. allow the use of a surefire.properties file with content like:

   foobar=${foobar}

Why properties file support for setting properties was removed for m2 I could never understand but it would be a nice quick way to solve this particular problem.

Note: This bug also breaks using profile properties which is a real PITA.

This bug is preventing us from using 2.4.3, as we're running our tests behind a proxy, i.e. ('mvn test -Dhttp.proxyHost=<proxyHost> -Dhttp.proxyPort=<proxyPort>), and the system properties http.proxyHost and http.proxyPort are being passed in as null. With 2.4.2, it works fine.

Can someone say when we can expect this to be resolved? Or if there's another workaround for the time being?

maven 2.1-M1 may have fixed it, could someone confirm?

btw, could some one provide a small pom to prove it?

I think I have a work around, may be cumbersome for some ppl

http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/system-properties/pom.xml

note the pom use the new systemPropertyVariables, the deprecated one systemProperties still work

Adding a simple project to reproduce the issue

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

+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 !!!

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

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.