On Mon, 7 Mar 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: >> Looks like a classloader issue (your test has been loaded from a >> different classloader than the class to test which means they are >> not inside the same package). >> >> There are other tests that rely on being in the same package, we >> exclude them via the tests.and.ant.share.classloader property. > > That's news to me. Could you explain a bit more the issue
The "package" a class belongs to really is not just the package name, but the pair of package name and the classloader that has loaded the class. When we run "ant test", our testcases are in a nested <classpath>. This means the tests get loaded by a separate AntClassLoader that is a child of the classloader that has loaded Ant itself. The tests will get loaded by that child, the classes to test by the classloader that has loaded the rest of Ant. Usually this doesn't matter in your own projects since the classes you want to test are also loaded by a child loader - only that in our case the classes under test are special. > and how it's dealt with Stefan please? We simply don't run the tests unless they are run by Gump right now - or you set up things "properly" (using build.sysclasspath). A better solution might be to add build/classes to <junit>'s <classpath> as well and somehow force ther AntClassLoader to not delegate to the parent. I'm not sure this would be a sane option, though. You'd end up with plenty of classes that have been loaded twice in a single classloader hierarchy. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
