ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: My itches for 1.6
Date Sat, 13 Jul 2002 23:47:38 GMT
On Sun, 14 Jul 2002, Peter Donald wrote:

> > > The sheel places them in the system classloader and thus a classloader like
> > >
> > > new URLClassLoader( new URL[] { myFile.toURL() } );
> > >
> > > include the ant classes (as they are in system classloader).
> >
> >You realize this is wrong and such code will fail in a container
> >environment. ( as general programming - for ant it may be ok ).
> It is not wrong. Thats the way ant was designed to work ;)

Passing the parent loader when you construct a URLClassLoader has
nothing to do with Ant - if you don't, your code won't work in 
any container environment, or in IDE that creates a loader explicitely,
and so on. 

It is true ant never had a proper design for the class loading - and
neither did tomcat - proper insolation of the container loader and 
allowing each webapp to use its own parser happened quite recently. 

> >Ok, would it be ok if the ant classes ( core, types, standard taskdefs )
> >are in the system loader, but the optional tasks are not ?
> Not for my tasks. They use junit and xslt liasons.

I see. 

Well, I think I found a solution that would work even in ant1.5 - by 
using the ProjectHelper pluging, and a reverse loader. Both 
models will continue to work - if you put everything in CLASSPATH, things
will work as before. If not - it'll be possible to define a Path where
junit and other jars are located and use it. 

Eventually I'll like this to be included in 1.6, but getting it working
in 1.5 is more important given the long release cycle. 


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

View raw message