ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: custom classloader for a task
Date Tue, 30 Aug 2005 07:46:49 GMT
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)
> its parent, to bypass the user/app classpath, but then you're kind of
> stuck because you most likely need to add ant.jar into your custom CL,
> and you reload the Ant classes from a different CL than the one Ant
> itself uses, which make the class be in fact different (even though
> its the same bytecode).

of course I know that ;) But how do I create a task using a custom 
classloader? Or did you talk about the case when forking?

> Ideally, when one starts Ant, only ant.jar would be on the classpath,
> and all other jars would be loaded off a custom class loader that
> 'extends' the app CL. That would allow to use different tasks with
> conflicting dependencies by making them live in different CLs.

ideally, yes.

> Maybe the -noclasspath switch would be useful too? Would force you to
> define explicit <classloader>s in build.xml for all non-core tasks,
> but could help? I've never tried such a thing.

do you have an example for this?

> Of course, the fact that you're having these problems in the context
> of Maven makes it even more complex with the tremendous dependencies
> Maven pulls in usually.

oh yes

> I'm afraid I haven't been very useful :-(  --DD

better than nothing ;)

bye blackdrag

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message