On 4/8/13 1:13 PM, Kristian Rosenvold 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 ? :)
Would this cause any problems with testing surefire itself? What about
those things surefire depends on at runtime, if there are any (I don't
remember off the top of my head)...
The point being that anything in the classpath to support surefire's
execution might conflict with something in the classpath to support the
test case itself. This is one reason shading makes a lot of sense IMO,
and probably the classloader structure too.
Having said that, I'd love to see things simplified, so hopefully I'm
full of crap on all this. ;-)
(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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
