I looked at something similar some time back and struggled with it - but that was pre-shading of providers and still having to deal with the forking to the old booter. I suspect the combination of both will make this more feasible, but it's long enough ago that I can't remember anything more specific. Good luck :)
- Brett On 08/04/2013, at 2:13 PM, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote: > Surefire currently uses this classloader architecture : > > Boot<----System<-----Test<----<Provider > > The "idea" is that while the test is executing, the "Test" classloader > is active, while the "provider" classloader hides all the provider > implementation details so they are invisible when the tests are run > (but provider is active before and after the test run). > > The thing is that the surefire providers have over time become very > aggressive users of the maven-shade-plugin, which means that we > relocate everything > of importance to private class name spaces. This must be done no > matter what since the Provider cannot load a class that will be later > required when running the test. > > Hence I'm contemplating just putting everything on the "system" > classloader when forking in surefire and just dropping the two extra > classloaders; I personally don't understand how that could change > anything ? (surefire does not claim to be a root-kit in the sense that > surefire is "undetectable"). It would also make the classpath of the > forked jvm more or less totally realistic and correct (apart from the > actual provider jar which would have to be there, unless we use > something like (the nonstandard) -Xbootclasspath to add the provider > to the boot classpath to make the system class path 100% correct) > > So tell me, what would this break ? :) > > (And yes, we have bugs and features related to this classloader > separation that would definitely make such a simplification > worthwhile. It´s actually a huge simplification) > > Kristian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
