We also need the possibility to use the settings file with the active profiles from a surrounding maven call inside a maven process forked by surefire via the org.apache.maven.it.Verifier. This is from my point of view a valid use case which is currently apparently not supported.
For build systems it is quite usual to use dedicated local repositories defined via -Dmaven.repo.local on the command line of the outermost maven call. Maybe you should consider to hand over that property also.

I think the default value for executionContextNamespace should be: org.apache.maven

@kpiwko
@gastaldi
@marcusholl
What can we do about this old issue?
My suggestion is to propose SPI in Surefire 3.x where hacking system properties in forked jvm would be fetched right from plugin process.
I want to have groovy scripting with interfaces in Surefire API instead of SPI. The interfaces will be compiled in Java 8 unlike most of other surefire modules compiled in Java 6.

@Tibor17 SPI would work for me. Basically any means how to get the information about Maven process to forked JVM would be helpful, if enabled by default, even better.

Enabled by default would mean to introduce a new feature and new bugs and
requirements in Jira.
The reason why we want the users to implement the API in their own is to
get freedom in Jira and solve contradictory issues.
It's pragmatic decision from our side. I understand that users would prefer
us to implement but we have limited resources.

On Thu, Sep 24, 2015 at 8:53 AM, Karel Piwko notifications@github.com
wrote:

@Tibor17 https://github.com/Tibor17 SPI would work for me. Basically
any means how to get the information about Maven process to forked JVM
would be helpful, if enabled by default, even better.

—
Reply to this email directly or view it on GitHub
#2 (comment).

Cheers
Tibor

Resolve #1790