I'd love to see this happening. We would be a big step closer to allow more user-defined providers or extensions, which could easily be added as plugin-dependencies, without having to worry too much on when to load what.
2013/4/8 Brett Porter <[email protected]> > 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 < > [email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- > Brett Porter > [email protected] > http://brettporter.wordpress.com/ > http://au.linkedin.com/in/brettporter > http://twitter.com/brettporter > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
