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