[ 
https://issues.apache.org/jira/browse/SUREFIRE-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15660296#comment-15660296
 ] 

ASF GitHub Bot commented on SUREFIRE-1301:
------------------------------------------

GitHub user rraumberger opened a pull request:

    https://github.com/apache/maven-surefire/pull/131

    [SUREFIRE-1301] add note for changing system properties when running 
parallel builds with disabled forking

    Resolves 
[SUREFIRE-1301](https://issues.apache.org/jira/browse/SUREFIRE-1301).

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/rraumberger/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/maven-surefire/pull/131.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #131
    
----
commit 059bd029ccfc56a0d9370f9862d4feed5fc07448
Author: Richard Raumberger <[email protected]>
Date:   2016-11-12T21:06:23Z

    [SUREFIRE-1301] add note for changing baseDir property

----


> baseDir system-property gets overridden by other builder threads if forking 
> is disabled
> ---------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-1301
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1301
>             Project: Maven Surefire
>          Issue Type: Documentation
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.19.1
>            Reporter: Richard Raumberger
>            Priority: Minor
>
> When running tests in a multi-module project with multiple builder threads 
> and surefire's forkCount set to 0, the threads override each other when 
> setting the baseDir system-property.
> Running the [sample 
> project|https://cloud.almost-a-blog.net/s/IHS63tBqowjhvBh/download] results 
> in the below output with the given commands.
> (Note: First number is the expected path. e.g. 11 => wrapper1; module1)
> *Correct*
> {code}
> mvn clean install | grep basedir
> 01 basedir=<path>/maven-surefire-example/module1
> 02 basedir=<path>/maven-surefire-example/module2
> 03 basedir=<path>/maven-surefire-example/module3
> 11 basedir=<path>/maven-surefire-example/wrapper1/module1
> 12 basedir=<path>/maven-surefire-example/wrapper1/module2
> 13 basedir=<path>/maven-surefire-example/wrapper1/module3
> 21 basedir=<path>/maven-surefire-example/wrapper2/module1
> 22 basedir=<path>/maven-surefire-example/wrapper2/module2
> 23 basedir=<path>/maven-surefire-example/wrapper2/module3
> 31 basedir=<path>/maven-surefire-example/wrapper3/module1
> 32 basedir=<path>/maven-surefire-example/wrapper3/module2
> 33 basedir=<path>/maven-surefire-example/wrapper3/module3
> {code}
> *Incorrect*
> {code}
> mvn clean install -T 3 | grep basedir
> 02 basedir=<path>/maven-surefire-example/module2
> 01 basedir=<path>/maven-surefire-example/module2
> 03 basedir=<path>/maven-surefire-example/module2
> 13 basedir=<path>/maven-surefire-example/wrapper1/module1
> 23 basedir=<path>/maven-surefire-example/wrapper1/module1
> 11 basedir=<path>/maven-surefire-example/wrapper1/module1
> 12 basedir=<path>/maven-surefire-example/wrapper2/module2
> 21 basedir=<path>/maven-surefire-example/wrapper2/module2
> 22 basedir=<path>/maven-surefire-example/wrapper2/module2
> 32 basedir=<path>/maven-surefire-example/wrapper3/module3
> 31 basedir=<path>/maven-surefire-example/wrapper3/module3
> 33 basedir=<path>/maven-surefire-example/wrapper3/module3
> {code}
> This is correct behaviour from a technical point of view as the 
> system-properties are shared between the threads and the surefire-executions 
> (due to the disabled forking), therefore I opened this issue mainly for 
> documentation purpose.
> This behaviour does not affect our current project anymore due to the removal 
> of the forkCount setting, yet I think that this behaviour should be 
> documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to