SUREFIRE-790 Added support for execution context propagation #2

Open
wants to merge 1 commit into from

4 participants

@kpiwko

No description provided.

@marcusholl

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.

@asfgit asfgit pushed a commit that referenced this pull request Dec 14, 2012
@hboutemy hboutemy svnpubsub configuration simplification #2: use mvn site site:stage
instead mvn site-deploy

BTW, this has others advantages:
- easier to understand (it's a local site staging, not a site deployment
to remote hosting)
- the distributionManagement entry has the real value, not a temporary
local storage location (which appears in Distribution Management report)
c7831f6
@gastaldi

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

@Tibor17

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

@kpiwko

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

@Tibor17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment