I would somehow assume that the sensible way to implement an android provider would be to extend the current forking logic to serialize the entire fork to a remote machine. Furthermore there is already support for bringing the system properties from the fork back to the plugin, which would come for "free" in this case. I would be considering starting the fork in/around the "ForkStarter" java class.
Something in your question makes me think you're starting the fork differently? Kristian 2012/6/13 Shane Isbell <[email protected]>: > Hi all, > > I'm working on an android provider for surefire. Generally, I have things > working but have encountered a specific problem. The unit tests are running > remotely on a device (not the build machine). For the surefire xml report, > I need to pull in the system properties on the device, not those on the > build machine. > > The StartupReportConfiguration.instantiateXmlReporter is hardcoded to > return XMLReporter. AbstractSurefireMojo.createForkStarter is, in turn, > hardcoded to use StartReportConfiguration. > > So I'm unable to replace the StartReportConfiguration with a class > implementation that will return a specialized XMLReporter instance that > will return device system properties. > > Is there a way to handle this situation through the surefire API or is this > something I need to create a patch for? > > Thanks, > Shane --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
