On Fri, 11 Jul 2003, Laird NELSON <[EMAIL PROTECTED]> wrote:
> I thought taskdef used a new AntClassLoader, as in Definer.java line
> 275? (Ant 1.5.3) I guess that must consult the system classloader
> first...?
Yes - unless you tell it not to, but that won't help.
You don't hand it any additional classpath entries in the snippet
you've posted, so the only classes available to this AntClassLoader
instance are those on the system classloader.
> Well, the dirty little secret here is that the project that is
> running this test case is actually using Maven,
Ts, ts, ts ;-)
> and I don't think Maven forks JUnit tests...I'll have to investigate
> this.
I'd be surprised if there wasn't a property like junit.fork or so that
you could set. There are many circumstances under which forking junit
is the only option. If you want to use a different DOM implementation
than the one used by the XML parser Ant is using for example. It's so
common, Maven will support it.
> I was playing around with Project.setCoreLoader(); perhaps I could
> set a classloader that *doesn't* delegate to its parent? Not sure.
You could give it a try. AntClassloader has a setParentFirst method
that you can invoke with false to suppress delegation. This in turn
gets exposed by <taskdef>'s reverseloader attribute.
Come to think of it, you can probably simply go ahead and add your
testcase's classloader as a reference to Project like
project.addReference("myid", getClass().getClassloader())
and use loaderref="myid" in your <taskdef>.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
