Andy, Thank you VERY MUCH! Setting maven.junit.fork=yes fixed the problem, just as you suspected!
I really appreciate the quick turn around! Brad -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Andy Glick Sent: Wednesday, September 07, 2005 2:31 PM To: [email protected] Subject: Re: Why Is Maven Using Different Class Loaders? Ward, Bradley (MAN-Corporate) wrote: > I've got a really strange thing going on with Maven (v. 1.0.2). It seems to > be using totally different class loaders depending on how I invoke Maven. > Are you familiar with the concepts of classloader parent-child hierarchies or of the classLoader class loading strategies used by JVM's? There are actually different policies used by different classloaders which can lead to a situation such as you have described that isn't necessarily a bug. Have you set the property "maven.junit.fork=yes" in your project.properties or build.properties file? I ask this because I have often experienced situations in which testcases fail using "maven jar:jar" when maven.junit.fork is not set to yes, which then succeed when it is. Looking more closely at the debugging lines that you have included, I would bet that you haven't set maven.junit.fork=yes, and I'll explain why. In the failing case, the classloader is the Ant classloader. That would be consistent with the following scenario: Maven is invoking JUnit via the JUnit Ant task, so the Ant classloader is active, therefore the testcase is running in the same JVM as Maven. In "maven site" case, it appears to follow a different scenario: the JUnit tests have been forked from the original process, so they are running in a new JVM. classloader that would be loaded and active in a newly forked process in a Sun JVM is quite likely to be sun.misc.Launcher$AppClassLoader, which your getClassLoader() invocation returned. So again, if you haven't set "maven.junit.fork=yes" please try that. If on the off chance that you have already set it and are still seeing this problem, then I've gone off on a wild goose chase, and you should probably write back providing more configuration information as well as the captured output from a failing run with the -X flag set. But as I said, the evidence that you've presented suggests a scenario similar to the one I've described. Here is the URL of Liang and Bracha's 1998 paper "Dynamic Classloading in the Java Virtual Machine". It isn't an easy read, but it is thorough. http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
