| back to <taskdef > classpath issues | back to <taskdef > classpath issues 2003-03-05 - By Mike McNally
A couple days ago I presented a problem I was having with using
<taskdef> to load up a task class with dependencies on a package
not part of the system classpath.
Further investigation (reading the source) reveals that the
Ant class loader can be instantiated either to load classes
preferentially with the system class loader (actually, its
parent class loader) or not. The code used by <taskdef>
uses a now-deprecated flag called "reverseloader" to determine
how the class loader is built. By default, they're built
such that the system class loader is tried first.
I appreciate that this is probably a wide-ranging rat's nest
of a problem, but I'm curious as to why the "reverseloader"
flag was deprecated, as it solves my issues completely.
Without it, my choices are
1) Modify my version of Ant, either the "<taskdef>" code or
the launcher script
2) Tell our developers to build without a CLASSPATH
3) Put classes I really don't want on the normal app CLASSPATH
in there anyway
None of those alternatives are as attractive as having the
ability simply to instruct Ant how to load my task.
If there's something icky about "reverseloader", then perhaps
the "build.sysclasspath" property could imply whether the
parent classpath is checked first; that doesn't seem so good
since I'm sure there are cases where the behavior is strongly
undesirable.
--
[ you are my main foo ] Mike McNally -- m5@(protected)
|
|
 |
