On Thu, 21 Feb 2002, <[EMAIL PROTECTED]> 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 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6606>, 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. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
