[SUREFIRE-416] Forked process inherits user.dir of parent process, multimodule builds behave differently from single module

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.4
• Component/s: process forking
• Assignee: Unassigned
• Reporter: Daniel Fabulich
• Created: 20/Dec/07 18:07
• Updated: 25/Dec/07 14:39
• Resolved: 25/Dec/07 14:39

Description

Make a test that depends on the user.dir system property (the current working directory), and put in a multimodule reactor.

When you launch the tests from the reactor, user.dir will be the reactor aggregator root. When you launch the tests from the individual module, user.dir will be the child's root.

Brett and I had a conversation about this on IRC. Ideally, we want user.dir to have the same default regardless of whether you're running in a reactor or not, and whether you're forking or not. We might wish that were the behavior of 2.3, but if not, we'll have to change the behavior to make the tests behave more logically.

To solve this, we're going to set user.dir to be ${basedir} when forking; when not forking we'll temporarily change the global system properties, and finally change them back. (This should be part of a more general test of systemProperties when not forking.)