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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
