Re: 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@...
>