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
