SUREFIRE-491 copying sys props to forked process

The sad tale of SUREFIRE-491 began when I tried to fix SUREFIRE-121.

http://jira.codehaus.org/browse/SUREFIRE-491
http://jira.codehaus.org/browse/SUREFIRE-121

The request seemed innocent enough.  Wouldn't it be cool if you could pass
system properties to your tests, like this?

   mvn clean test -Dbrowser=firefox

Apparently this used to work in an earlier version of Surefire, even.
What could go wrong?

Well, a lot actually, because these days Surefire runs the tests in a
forked process by default; passing system properties to the forked process
means copying all system properties to the child.  I knew this was
risky...

http://www.nabble.com/passing-system-properties-to-forked-test-td13947630.html

I even included a comment in the code: "Is this wise?"
http://svn.apache.org/viewvc/maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java?r1=598217&r2=598216&pathrev=598217

It turns out that it was NOT wise.  What if the child is running a
different version of Java?  Copying all system properties means copying
the java.specification.version into the child, so the child thinks it's
running the same version as the parent.  It gets even sillier; we copy
java.class.path from the parent to the child, so while the classpath may
be correct, the system property is not.

At this point, I'm tempted to resolve SUREFIRE-491 by breaking
SUREFIRE-121 again and marking it "Won't Fix", preventing the user from
passing system properties to forked tests simply by specifying them on the
command line.  It's convenient, but I just can't see any way to support it
safely.

Any other suggestions before I just roll ahead with this?

-Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...