ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject Re: custom classloader for a task
Date Tue, 30 Aug 2005 00:15:35 GMT
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).

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.

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.

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.

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

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

View raw message