Bug 40522

Summary: [Patch] Fix coreloader so that it works
Product: Ant Reporter: Peter Reilly <peterreilly>
Component: CoreAssignee: Ant Notifications List <notifications>
Status: NEW ---    
Severity: normal CC: robert.flaherty, tseigne
Priority: P2 Keywords: PatchAvailable
Version: 1.8.2   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: patch of changes to fix coreloader

Description Peter Reilly 2006-09-15 14:29:34 UTC
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
Comment 1 Peter Reilly 2006-09-15 14:32:01 UTC
*** Bug 21635 has been marked as a duplicate of this bug. ***
Comment 2 Peter Reilly 2006-09-15 14:33:57 UTC
Created attachment 18870 [details]
patch of changes to fix coreloader
Comment 3 Matt Benson 2006-09-15 15:19:20 UTC
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?
Comment 4 Peter Reilly 2006-09-15 16:04:25 UTC
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).


Comment 5 Gilles Scokart 2009-07-31 11:01:11 UTC
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