Allow forked process to access the Maven session of parent

Can you give a clearer indication as to why a test should need to be resolving dependencies on its own ? Some specific use cases seem to be in order, since this issue on first looks seems like a clear "wont' fix" to me.

My specific use case is using Maven together with Arquillian for testing Java EE applications.

Arquillian is building the test archive using Java programmatic API (ShrinkWrap), e.g. creating a minimal archive required to reproduce a bug/test a feature. This allows tests to be run much faster and from IDE without any boostrap steps needed.

However, it might happen that user have to include a jar file in the test archive. In that case, Aether is used via an ShrinkWrap extension. Aether has no information that Surefire plugin started it, so pom.xml and settings.xml have to be specified once again in the test itself.

This leads to:
1/ The information is duplicated
2/ If user activates a profile or pass different settings.xml file, it expects that they will be passed to the test as well.

The key here is to be reproducible in both IDE and CLI. We can't simply move to e.g. integration-test where we can expect dependencies are already resolved somewhere in target/directory as this is not the way how neither of the IDEs work.

The idea here is to be at least able to access path to settings.xml, pom.xml and activated profiles, so it would be easy to reproduce the same environment in "test Aether", no reason to make whole MavenSession serializable although that we be nice.

How does this sound to you?

It also sounds like you should be writing a "arquillian-maven-plugin" that does the ShrinkWrapping, artifact resolution and project modification /prior/ to invoking surefire in a regular fork.

Generalized access to the "session" within the forked process is just /not/ going to happen if I understand anything at all; something aether specific maybe. The fork is designed to stay minimalistic and "clean" and this suggestion certainly breaks that constraint totally.

Writing a specific plugin does not really help here, because the test itself is responsible for the packaging.

If we move this responsibility to the plugin, we would have an intermediate step. This means that we can't update the test from the IDE on-the-fly, we have to store the step result somewhere on the filesystem, etc., making test development much more difficult.

Plugin would not be able to build multiple packages, specific packages per container, etc., basically it will loose all advanced Arquillian features.

I've created an implementation of this feature, you can check the code in pull request https://github.com/apache/maven-surefire/pull/2.

How does it work?

<configuration>
    <propagateExecutionContext>true</propagateExecutionContext>
    <!-- optional -->
    <executionContextNamespace>maven.execution</executionContextNamespace>
</configuration>

This will make following system properties available in either forked/non-forked tests

• maven.execution.pom - pom.xml file currently executed, e.g. actual pom file (not the parent for multimodules)
• maven.execution.user-settings - path to user settings.xml (e.g. mvn -s)
• maven.execution.global-settings - path to global settings.xml (e.g. mvn -gs)
• maven.execution.activeProfiles - list of active profiles in the project
• maven.execution.offline - offline flag (e.g. mvn -o)

This extension uses reflection, the very same way as SUREFIRE-121 and requires Maven 3.0.x to get MavenExecutionRequest object. If will log a failure.

Integration test is included.

As this is disabled by default, I'm convinced that the clean constraint is not violated.