>>> On Tue, 13 Nov 2001 17:20:38 +0100 (CET),
>>> "Holger" == Holger Engels <[EMAIL PROTECTED]> wrote:
Holger> The point is, that the tool's jars are loaded from the same
Holger> classloader as the tasks. As optional.jar is in the system
Holger> classloader, junit.jar has to reside there, too.
Actually, the <junit> task is an excellent example. As a developer, I want
to ensure that the junit.jar used by the task is the same version I
compiled my unit-tests with. To achieve this now, I have to rely on
external CLASSPATH setup before invoking Ant. That smells.
This prompts me to ask the questions:
- Who should be in-control of the classpath for optional tasks: the Ant
user (who writes build.xml) or the Ant deployer?
- Why include the "optional" tasks on Ant's classpath, when they won't
work without additional setup?
Personally, I'd prefer that (for instance) the <junit> task was NOT on the
classpath by default. Then, I could explicitly declare in my "build.xml",
e.g.
<taskdef name="junit"
classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask">
<classpath>
<pathelement location="${junit.lib}/junit.jar" />
<pathelement location="${ant.lib}/optional.jar" />
</classpath>
</taskdef>
--
cheers, Mike
"Hand over the coffee and no one gets hurt."
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
