maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject Re: Simplifying surefire classloader stucture.....
Date Mon, 08 Apr 2013 18:24:29 GMT
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:
> For additional commands, e-mail:

John Casey
Developer, PMC Member - Apache Maven (
GitHub -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message