2013/4/8 John Casey <jdca...@commonjava.org>: > On 4/8/13 1:13 PM, Kristian Rosenvold wrote: >> Surefire currently uses this classloader architecture : >> >> Boot<----System<-----Test<----<Provider > Would this cause any problems with testing surefire itself? Nope. Currently surefire shades /everything/ in the junit3 provider to a different location to test itself.
> What about those > things surefire depends on at runtime, if there are any (I don't remember > off the top of my head)... That's m-s-u and a couple of other things. All dependencies are effectively shaded already. The thing about the current design is that when the provider classloader is active before the test is being run, we can *never* load anything that can appear in the test classloader since we could potentially load different versions. So it all has to be shaded anyway, which IMO just shows that the current classloader structure looks good on paper but is useless IRL. > > 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. Well with the new classloader structure we'd have a jar full of surefire classes swimming in the same classloader as the actual tests (or use endorsed jars to put surefire in the boot loader to get 100% correct system class path) (the surefire jar would have everything shaded away somewhere deep below org.apache.maven.surefire.shade - much like today) > > Having said that, I'd love to see things simplified, so hopefully I'm full > of crap on all this. ;-) i think this is one of those areas where this mailing list has a lot of knowledge, so discussing it is a Good Thing :) Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
