I thought I had commented on this at some point, but I don't really
remember.
You're plan of action sounds correct if there's no way around it. You
might however look into the changes John made in 2.0.9 to separate CLI
properties from existing system properties - maybe we can just support
it under 2.0.9 using these?
- Brett
On 02/05/2008, at 12:18 PM, Dan Fabulich wrote:
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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
