Return-Path: 
 <ant-dev-return-11451-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 80833 invoked by uid 500); 14 Mar 2001 09:08:53 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 80807 invoked from network); 14 Mar 2001 09:08:50 -0000
X-Authentication-Warning: bodewig.bost.de: bodewig set sender to
 bodewig@bost.de using -f
To: ant-dev@jakarta.apache.org
CC: William Lee <wlee@sendmail.com>, David Zeleznik <zeleznik@ilog.com>
Subject: <taskdef>s with nested classpath for "built-in" tasks
From: Stefan Bodewig <bodewig@apache.org>
Date: 14 Mar 2001 10:08:52 +0100
Message-ID: <m366hc7m57.fsf@bodewig.bost.de>
Lines: 34
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

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