ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: cvs commit: ant/src/testcases/org/apache/tools/ant
Date Mon, 07 Mar 2005 16:38:30 GMT
On Mon, 7 Mar 2005, Dominique Devienne <> 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

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.


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

View raw message