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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
