ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Dealing with ClassLoaders
Date Sat, 23 Feb 2002 11:32:01 GMT
From: "Stefan Bodewig" <>

> On Thu, 21 Feb 2002, Jose Alberto Fernandez <>
> wrote:
> Let's take the example of the <style> task, how can we solve the
> scenario "I don't want Xalan in my system classpath" without breaking
> backwards compatibility in your opinion?
> I think I must be misunderstanding something of your proposal.

<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.

Now to the point:

Here is a sketch og the directory structure for ANT_HOME:

        ant.jar   (loaded in the CLASSPATH)
        xml.jar  (maybe, I am not sure who uses this thing)
        some-more-opt.jar (this two jars are loaded in the in the loader named: "" at startup)
            some-xalan-opt.jar (this jar will be loaded in loader named: "xalan")
            some-junit-opt.jar (this jar will be loaded in loader named: "junit")
        (Here you put any libraries to be loaded manually with <antlib library='xxx.jar'
/> )

Everything in lib and autolib is loaded and the tasks registered when ANT comes up.
The jars may use Class-Path in their manifest to load other jars if they so want.
So, for the common user, when ANT starts you have your definitions just as before.

<antlib> will use by default the "" loader, but you can change that by specifying a
different loaderid. This means that your classes will be added to that classloader.

In the case of <style>, I am sure we can find a place for it that will not cause the
we have since we can isolate it. It may have to move out of ant.jar itself but I really do
see this as a big deal. If someone really needs it in the CLASSPATH for some obscure reason
he can put it back and it will behave just as in ANT1.4.

Warning: this part I have not thought completely through, so they are just ideas.

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 ""). And would also like to add to <classpath> the ability
to specify a loaderid to use for its parent. This is how one passes the information 
to AntClassLoader of what to do.

But is a task does not use this new facilities, it will just behave as before and in certain
casess may require move things to 'lib' just like we required people to dowload optional.jar
or junit.jar or whatever a an additional step.

Hope this makes things more clear,

Jose Alberto

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

View raw message