project.setCoreLoader(Classloader x) has been part of the ant code base for quite a long time, (it was orignally called project.setSystemLoader(Classloader x)). Currently it does not do anything usefull, but with a few modifications it can be made to work again. 1) change antclassloader to use the core loader as a parent loader 2) when the coreloader is changed update all the non resolved tasks and types that use the coreloader to use the new core loader. Two other changes are also necessary: 1) when the coreloader is set, ensure that it can be used to resolve Project correctly. 2) modify oata.taskdefs.Classloader to add types.optional and util.optional to its addLoaderPackageRoot list. When these changes are made, <classloader> works. <classloader> has been in the ant code since 1.6, but has not been docuemented. With these changes one can do the following: <project ... xmlns:ac="antlib:net.sf.antcontrib"> <classloader> <classpath> <pathelement path="c:/apps/jdepend-2.9.1/lib/jdepend-2.9.1.jar"/> <pathelement path="${ant.home}/lib/ant-jdepend.jar"/> <pathelement path="c:/apps/ant-contrib/build/lib/ant-contrib.jar"/> </classpath> </classloader> <jdepend> .. </jdepend> <ac:for ... <ac:for
*** Bug 21635 has been marked as a duplicate of this bug. ***
Created attachment 18870 [details] patch of changes to fix coreloader
How does the example below differ from your <appendprojectpath> prototype task? Is it that fixing this code that is already "polluting" our released codebase by being present in a less-than-wholly-working state, that the need for <appendprojectpath> would be obviated?
It is more similar to the <addlibpath> When I introduced that, I said that it is similar to the coreloader stuff, which I could not get to work. The main difference is that the coreloader code does not need to modify a classloader. There are a number of things to be done to make it rock solid, (handling of <antcall> <ant> etc, easier handling of ant-<optional> jars etc, modification of <classloader> task to only handle the coreloader and not other classloaders (this is done *much* better by Rainer's http://jtools.org/ant-classloadertask task). the <appendprojectpath> task is a simplified copy of Rainer's task, it only handles the project classpath and assumes that it is URLClassLoader. The latter assumption may not be true if ant is used outside of ant[.bat] (say in a web application).
Fixing this will also make it easier to launch the test of the antunit build (by avoiding the need to put all the classes and the test classes in the ant classpath). See http://markmail.org/thread/5bbknx6hm7liqvi6