ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Williams <mi...@cortexebusiness.com.au>
Subject [PROPOSAL] don't include optional.jar in the system classpath
Date Tue, 13 Nov 2001 22:31:40 GMT
  >>> On Tue, 13 Nov 2001 17:20:38 +0100 (CET),
  >>> "Holger" == Holger Engels <hengels@mercatis.de> 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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message