ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: We need to stop the lies
Date Fri, 22 Feb 2002 09:15:47 GMT
On Thu, 21 Feb 2002, <> wrote:
> On 21 Feb 2002, Stefan Bodewig wrote:

>> I'll add it to the FAQ and link it from the manual.
> Sounds great ! It would be a good jakarta-wide resource, the
> exact same problem happens for people using webapps for example.

I'll be happy to share, my starting point - very Ant centric, od
course - is <>,
please take a look at what I have so far and lets see whether we can
improve from that.

>> >> What do people think of breaking optional.jar into several
>> >> pieces cut along the dependencies, optional-junit.jar,
>> >> optional-trax.jar and so on.
> +1, great idea.
> What I don't like is the fact that we load optional.jar and what's
> inside in the 'parent' class loader.

This is what I've called "the problem that cannot be fixed in a
backwards compatible way" - I'd be happy if you could prove me wrong.

The main classloader problem of Ant 1.x is, that there is far too much
stuff on the system classloader IMHO, but I'm really afraid that there
are lots of people who rely on Ant having its own classes just there.

> I liked very much the idea of using named loaders, and a model
> similar with what tomcat is using ( either version, but 3.3 in
> particular :-).

Your description sounds a lot like Conor's of Mutant's class loader
hierarchy (see proposal/mutant/docs/desc.html) and Myrmidon does
something similar IIRC.  So you we all basically agree that having a
class loader hierarchy like that is the way we should go -
unfortunately this is not backwards compatible for the things that
have been shipping with Ant before.

If we start shipping new tasks in extension libraries that get loaded
from named class loaders, that is fine, but for the things that used
to be on the system classloader, we must still ensure they stay there.


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

View raw message