ant-dev mailing list archives

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

a while back William Lee reported a problem on ant-user
<http://marc.theaimsgroup.com/?t=98346905700004&w=2&r=1> - 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
junit.framework.TestListener.

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 org.apache.tools.ant.* to be
loaded via the system classloader first - this has to be done to make
sure the "right" org.apache.tools.ant.Task 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
org.apache.tools.ant.*".

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

Stefan

[usual rant about classloader omitted]

---------------------------------------------------------------------
To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org


Mime
View raw message