Interesting post; you suggest that the surefire-providers should have extensive freedoms in terms of controlling details of the fork, I like that suggestion a lot, it's a very good extension of the current provider api.
I'll give you some pointers into the code on this; The org.apache.maven.surefire.providerapi.SurefireProvider interface would definitely need to have some kind of method(s) to allow the provider to influence the fork. You'll need to be looking at org.apache.maven.plugin.surefire.booterclient.ForkStarter, and at some point you /will/ be modifying org.apache.maven.plugin.surefire.booterclient.ForkConfiguration You'll also be looking at getSuitesIterator in ForkStarter, which is where the provider is queried before starting the fork, this is typically the same kind of logic you'd be looking at. All patches to surefire require some kind of test coverage, and in this case you'll at a minimum want to launch one of the existing providers with a set of vm options that can be asserted. A look at Surefire763EnvironmentForkModeIT and the corresponding /surefire-integration-tests/src/test/resources/environment-variables will get you a long way. I will definitely review any patches you supply in this area, I love this feature ;) But please take note that I am also working in this area of the code trying to simply things further, so please stay in synch with trunk. Kristian 2011/12/9 Andreas Sewe <[email protected]> > Hi all, > > and sorry for the long post; what I want to acieve is a bit complex: > > I am currently integration-testing a tool that allows one to perform a > variety of bytecode instrumentation tasks (for profiling/JVM research). > Said tool consists of two components: a server running in a separate JVM > instance that does the actual instrumentation and a client that > intercepts classloading on the target JVM, sends the classes to the > server to be instrumented, and then inserts the instrumented classes > into the target JVMs class-loading process again. > > Currently, I envision testing a particular instrumentation like this: > > pre-integration-test: > Use a Maven goal similar to jetty:start to start the server process. > (Writing such a plugin is relatively straight-forward :-) > > integration-test: > Use the maven-failsafe-plugin to execute the integration test under > the client's regime, i.e., with instrumentation being build > activated. > > post-integration-test: > Use a Maven goal similar to jetty:stop to stop the server process. > (Again, this is straight-forward.) > > The tricky part is the integration-test phase. Ideally, I would like to > re-use the maven-failsafe-plugin here, but in order to make the target > JVM communicate with the instrumentation server I need to pass a whole > bunch of arcane options to the (forked) JVM (-javaagent, -agentpath, > -Xbootclasspath/p, not to mention the paths to the various JARs). What I > would thus like to do is hide these details the the user. (Just like > start/stop goals hide the details of starting/stopping the server.) > > Can the Surefire Provider API be used for something like this, e.g., by > extending the existing JUnit-Provider and modifying the ForkConfiguration? > > Any pointers are greatly appreciated. The documentation at > <http://maven.apache.org/plugins/maven-failsafe-plugin/api.html> is > sadly rather brief. > > Best wishes, > > Andreas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
