first, thx for all your help from everyone. To solve my problem I wrote
a task that will store a laoder reference for the usage by my taskdef.
That classloader does try to load all classes by himself instead
delegating these classes to the parent as a normal classloader would do.
To avoid dupli
e tasks is IMHO mostly allways the best solution).
Cheers
Rainer
> -Original Message-
> From: Jochen Theodorou [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 10:49 AM
> To: Ant Users List
> Subject: Re: custom classloader for a task
>
>
> Conor MacNeil
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 envirome
Dominique Devienne schrieb:
Well, I think you summed it up pretty well. Forking is IMHO a good
solution to avoid these conflicting jars, since you fully control the
classpath of the forked VM. I guess you could create your own
classload, and make the root classloader (the one which loads rt.jar)
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 m
Well, I think you summed it up pretty well. Forking is IMHO a good
solution to avoid these conflicting jars, since you fully control the
classpath of the forked VM. I guess you could create your own
classload, and make the root classloader (the one which loads rt.jar)
its parent, to bypass the user
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
