ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: classloader for 1.7
Date Tue, 29 Aug 2006 16:44:40 GMT
I can see some problems with this approach.
The classloader hierarchy currently is: (using

bootstrap (rt.jar etc)
extension (jre/lib/ext/*.jar)
system loader (ant-launcher.jar)
project (ant.jar + contents of $ANT_HOME/lib + ~/.ant/lib)
taskdef ...

For  netbeans the hierarchy is similar:

bootstrap (rt.jar etc)
extension (jre/lib/ext/*.jar)
system loader (netbeans stuff)
project (ant-launcher.jar ant.jar + contents of $ANT_HOME/lib  (as entered
by the user) + ~/.ant/lib (as entered
by the user)
taskdef ...

So what would be the hier for the secondary class loader?
if it is bootstrap->ext->system->project->secondary,
it would meant that the classes in project would not be able to see the
secondary classes.


On 8/28/06, Jesse Glick <> wrote:
> Peter Reilly wrote:
> > The antlibs solution would be ok, but it does not solve ant optional
> tasks
> Perhaps we could arrange for tasks in the standard distribution not to
> be loaded until actually used. (This might be a performance win anyway.)
> Rather, the Ant core would create a new AntClassLoader in which all
> tasks were loaded (unless an explicit <classpath> were given to
> <taskdef>). Then you could have a task similar to <classloader> which by
> default appended entries to this secondary class loader. E.g.
> <lib file="libs/oro.jar"/>
> <replaceregexp .../>
> Then the URLClassLoaderAdapter would be unnecessary since the Ant core
> class loader would never need to be touched.
> -J.
> --
>  x22801
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message