ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <>
Subject Taskdef Classloader change (was RE: Custom Ant tasks and classpath issue)
Date Thu, 28 Feb 2002 10:29:05 GMT
Ah ok. Thanks Stefan for the clarification. Is that the way we want Ant
to operate ? Don't you think it would be better if the "reverseloader"
mode was the default one. It would be backward compatible in all cases
except for persons like who were counting on their classpath was being
picked before the system classpath.

I do agree, it is not nice to have my jar in both places. It wasn't
actually meant that way. I had just dropped my cactus-ant.jar in
anthome/lib a long time ago for some quick test I did ... and had
forgotten about it ... until 3 months later I had to change one task ...

I think it is safer to load the user classpath before the system
classpath, making the user classloader a child of the system

What do you think ?

> -----Original Message-----
> From: Stefan Bodewig []
> Sent: 28 February 2002 09:31
> To:
> Subject: Re: Custom Ant tasks and classpath issue
> On Wed, 27 Feb 2002, Vincent Massol <> wrote:
> > I have just discovered today that Ant seems to put java.class.path
> > by default in the task classpath. Thus, the second pathelement entry
> > is actually not needed.
> Hmm, no, not really.
> Ant uses a delegating class loader, i.e. it will ask the system
> classloader to load your task before even looking at the classpath you
> have specified (and that's the reason why the build.sysclasspath
> setting doesn't change anything).
> <taskdef> has an undocumented and deprecated reverseloader attribute
> that would make Ant consult the classpath you have specified before it
> asks the system classloader.
> Stefan
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message