ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Dealing with ClassLoaders
Date Mon, 25 Feb 2002 16:36:21 GMT
On Sat, 23 Feb 2002, Jose Alberto Fernandez <>

> <style> is a little special because it is (I think) the only task in
> the core packages that requires things outside ANT's core. See all
> the discussion about moving <style> to optional.

No reason to move the implementation of the <style> task out of
ant.jar, the implementations of XSLTLiaison need to be separate, and
they are in optional.jar already, thus would end up in a different
classloader in your setup anyway.

>         xml.jar  (maybe, I am not sure who uses this thing)

Nobody, if you have one, remove it 8-)

> Everything in lib and autolib is loaded and the tasks registered
> when ANT comes up.

How would I add xalan.jar and xml-apis.jar to the class loader named

> Now for the old things that create their own AntClassLoader.  I
> would like to be able to instruct AntClassLoader to attach itself to
> a particular loaderid (the default being "").

Which would be: the AntClassLoader in style attaches itself to, err,
what?  We'd have trax, xalan and xslp for the three Liaison
implementations.  Let the user specify it?

> And would also like to add to <classpath> the ability to specify a
> loaderid to use for its parent.

OK, I make "trax" the parent.  Style loads the Liaison via
AntClassLoader named "trax" (as it is the parent class loader), it
will be found, <classpath> has been set to include xalan and xml-apis,
but these elements will not be found by the "trax" class loader, they
are in a child of this loader.

Does that mean we add the user specified classpath elements to the
named class loader to avoid delegation?


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

View raw message