Stefan Bodewig wrote yesterday on the development list :
Hi,
the new Launcher introduces the well known fun of delegating
classloaders to <taskdef>, only this time it's the other way around.
If you use <taskdef classname="org.example.Foo"/> and Foo is on the
system classloader, but ant.jar is not, <taskdef> will fail as it
cannot load oat.ant.Task.
This used to work as long as all contents of ANT_HOME/lib ended up on
the system classloader, but now it fails.
There is no difference if Foo comes from a jar in ANT_HOME/lib, only
if it is in CLASSPATH.
Stefan
----- Original Message -----
From: "Laird NELSON" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 11, 2003 4:06 PM
Subject: Buildfile testing (again)
> Hello; I am trying to unit test a build file from within JUnit. I
> received some helpful advice from this list on how to do this, but
> unfortunately it didn't work. The advice was essentially, "Don't use
> Main.start(); put your Project together by hand, like BuildFileTest
> does." Or, in other words:
>
> . Write a TestCase that creates a Project manually
> . Call project.init()
> . Call project.setUserProperty("ant.file", new File
> (buildFile).getAbsolutePath))
> . Call ProjectHelper.configureProject(project, new File(buildFile))
> . Call project.executeTarget(targetName)
>
> This is exactly, unfortunately, what Main.start() does, which is what I
> *had* been using earlier, but which didn't work either.
>
> The problem I'm getting is that my taskdef, which is in the same
> package as my TestCase, is not seen by whatever classloader it is that
> loads taskdefs. So my buildfile looks something like this:
>
> <?xml version="1.0" ?>
> <project basedir="." default="test">
> <taskdef name="foo" classname="com.foo.Bar"/>
> <target name="test">
> <foo blee="blah"/>
> </target>
> </project>
>
> I get an error that begins with this:
>
> taskdef class com.foo.Bar cannot be found
>
> ...and is caused, in turn, by ClassLoader.loadClass() blowing up.
>
> Now, my classpath is set up properly, because my TestCase is loading
> and running (obviously). And I would think that if *it* can be loaded
> then the taskdef class, which is in the same package, could *also* be
> loaded. Is there something else I have to do to enable ant's tangled
> guts to look in the right place to find my taskdef class?
>
> Cheers,
> Laird
>
>
> ---------------------------------------------------------------------
> 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]
