ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject <taskdef>s with nested classpath for "built-in" tasks
Date Wed, 14 Mar 2001 09:08:52 GMT

a while back William Lee reported a problem on ant-user
<> - with the
help of David Zeleznik I finally could identify the problem.

William wanted to use a <taskdef> for the JUnit task with a classpath
of its own. The reason was that JUnit itself should not be part of the
"normal" CLASSPATH.

Whatever he tried, he always ended up with a NoClassDefFoundError for

The problem is, that the task implementation was in optional.jar in
ANT_HOME/lib - and therefore can be loaded via the system
classloader. Taskdef enforces classes in* to be
loaded via the system classloader first - this has to be done to make
sure the "right" will be used - and so the
task implementation *will* be loaded from the system classloader.
After that, Ant will never even try to load JUnit from something other
than the system classloader - and will fail.

The only solution I see is to either remove optional.jar from
ANT_HOME/lib - or remove the junit task implementation from it.  Add
some clarification to the docs - something along the lines of
"classpath will have no effect if you define a task that is in your
CLASSPATH and lives in a package that starts with*".

I see no code solution to this problem, but maybe others do.


[usual rant about classloader omitted]

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

View raw message