ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McNally ...@works.com>
Subject back to <taskdef> classpath issues
Date Wed, 05 Mar 2003 18:05:31 GMT
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@works.com

Mime
View raw message