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.
Peter
On 8/28/06, Jesse Glick <[EMAIL PROTECTED]> 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.
--
[EMAIL PROTECTED] x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
