Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.4.3
-
Fix Version/s: 2.4.3
-
Component/s: process forking
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
Run a Surefire test with a different JVM using the -Djvm argument. For example, run the test with JDK 1.4 while running Maven with a 1.5 or 1.6 JVM.
Examine the XML file in target/surefire-reports corresponding to your test. The java.* properties will match the parent process, not the forked process. For example, <property name="java.version" value="1.6.0_02"/>.
Issue Links
- is depended upon by
-
SUREFIRE-510
surefire.test.class.path is not set when forkMode is always
-
- is duplicated by
-
SUREFIRE-461
-Xbootclasspath specified in <argLine> not passed to forked JVM
-
-
SUREFIRE-552
CLONE --Xbootclasspath specified in <argLine> not passed to forked JVM
-
- relates to
-
SUREFIRE-121
System properties set on the command line get clobbered
-
-
SUREFIRE-512
Provided Properties no longer visible in Surefire-Tests
-
This is happening due to the fix for
SUREFIRE-121. I was afraid when I did this that it 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?
In hindsight, it was not wise; the initial implementation broke the embedder. Milos fixed that later, but it's still doing the wrong thing from the command line.
I'm not exactly sure how to fix this without breaking the fix available in
SUREFIRE-121...?