ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: custom classloader for a task
Date Tue, 30 Aug 2005 08:48:43 GMT
Conor MacNeill schrieb:

> 
> Jochen Theodorou wrote:
> 
>>Hi all,
>>
>>Te problem I have is a little complex but I hope you can help me. Groovy
>>has an ant task to compile groovy classes and a task to use groovy from
>>within ant see http://groovy.codehaus.org/Groovy+Ant+Task for details.
>>But in some enviroments such as in maven with certain plugins we have
>>conflicting jars. I mean jars of a different version than needed by
>>groovy. For example antlr or asm.
>>
>>Our current workaround for the compile task (groovyc) is to fork the VM.
>>But this can't be the solution? I mean isn't there a possibility to load
>>a task through a custom classloader? It's no problem for me to write
>>such a loader, but where to wire it in? I know about the loaderref
>>attribute, but as far as I understand this attribute is for reusing a
>>classloader. A normal classloader can't be used since a normal
>>classloader looks for a class first in the parent and if the parent
>>knows the conflicting jar/class then we have the same problem as before.
> 
> Since you are passing a classpath to the taskdef above, Ant will create
> a classloader to load this task's classes. What classes this classloader
> can see will depend on the classloader hierarchy under Maven. I have no
> idea what that will be.

classloader hirarchy for the task class without loaderref:

class org.apache.tools.ant.AntClassLoader
class sun.misc.Launcher$AppClassLoader
class sun.misc.Launcher$ExtClassLoader

printed by a task:

     public void execute() throws BuildException {
         ClassLoader loader = this.getClass().getClassLoader();
         while (loader!=null) {
             System.out.println(loader.getClass());
             loader = loader.getParent();
         }
     }

so it seems maven does not change the hirarchy...

> It is possible to specify a reverseloader="true" attribute on an Ant
> taskdef. It is highly deprecated, unsupported, bad things happen, etc.
> It will cause the classloader to consult it's jars first, before those
> of its parent.

well, reverseloader=true might be the thing I am searching for, and a 
test shows it works then... But these deprecated warnings are annoying. 
No way to work around this problem?

>>I heard that when you do loaderref="root" in a maven project you get the
>>ant-loader, but that will be no help if the normal classpath contains a
>>conflicting jar for another task. Maybe someone can explain me if a
>>classpath from a taskdef is added to the loader reffered by loaderref.
>>If so the ant-loader will be polluted too.
> 
> No, this does not happen - loaderref and classpath are exclusive, I think.

my tests are showing that with a loaderref I hae a different 
AntClassLoader, than the normal Classloader, but I have still the 
conflicting jar. When I enable reverseloader, then it's ok. So the new 
Loader has to share some classpath parts with the normal antloader 
somewhere, because I am sure the sun.misc.Launcher does not caontain 
that jar.

by blackdrag

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message