ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <>
Subject Re: 1.1 compat ( was Re: Death of a mutant ...
Date Tue, 16 Jul 2002 01:24:43 GMT
I recall sending a reply to this one, but it seemed to get lost in the 

Peter Donald (7/12/2002) wrote:

> Along with the syntactical differences of ant1.x to ant2 there is also 
> slightly semantic changes and unless you are aware of these changes 
> your build wont work anyways. Consider the following;
> <project ...>
>   <path id="x" dir=".">
>     <pathelement location="nonexistant/file.txt"/>
>   </path>
>   <target name="X">
>   </target>
>   <target name="Y">
>     <property name="x.prop" refid="x"/>
>     <echo message="x=${x.prop}"/>
>   </target>
> </project>
> In Ant1.x you could run target X fine. However if you tried to run Y 
> it would generate a
> "Error: nonexistant/file.txt does not exist!" (or similar)
> This is because Ant1.x delays evaluation of some constructs until they 
> are referenced. Where as in Ant2 the idea was to unify all evaluation 
> of "build model" to when execution occurs. So in Ant2, the <path/> 
> data type would be evaluated imediately before any target was executed 
> and thus would generate an exception regardless of target.
> This becomes especially painful when you are dealing with things like 
> filesets. You have to decide when the list of files is evaluated. Is 
> it when declared, when it is first used or everytime it is referenced? 
> In ANt1.x it is kinda haphazard (first time referenced unless it does 
> not have any propertys to expand in which case it is declaration) and 
> getting it to work consistently with Ant2 datatypes is a little 
> painful (though possible).
> Other build systems GNUMake (and CONS from what I hear) explicitly 
> allow user to declare whether filesets are re-evaluated every 
> reference or just once etc. I would love for Ant to get to the same 
> level of clarity.
> This is just one of the peculiarities of the way ant as it has grown 
> up and one peculiarity that we would like to fix in Ant2 (but is 
> incompatible with Ant1.x). Other changes that are incompatible ways of 
> evaluating propertys. ie In Ant2 it is mostly decided that ${x} should 
> throw an exception if x is undefined but this behaviour is different 
> (and incompatible) with ant1.x.
> These are just two issues that imediately come to mind when executing 
> ant1.x files in ant2. While the syntax of ant1.x can be easily 
> translated into ant2 and the Task API can easily be adapted between 
> the two versions. There are still real issues that need special handling.
> Hence why I believe that there will be no simple transformation of 
> ant1 build files to ant2 buildfiles. Or if there is the transformed 
> buildfiles will have to have directives to ant runtime that indicate 
> it should operate in certain ways. (ie One directive may indicate that 
> unresolved proeprtys should not cause an exception to be thrown)
>> <!--  Ant 1   -->
>> <project>
>> <!--  Ant 2   -->
>> <project xmlns="">
> Or even more simply...
> <project> <!-- ant1.x -->
> <project version="2.0"> <!-- ant2 -->

It seems like a undesirable change to have a reference to a type 
definition do something different than copying the same code inline.  In 
current Ant 1.x files, references are used to minimize boilerplate 
constructs.  If a reference is no longer identical to inlining the same 
content, then you have to use entity references when you really want to 
just have the same constructs repeated.

It seems like there are two use cases:

1. Reusing a type definition in multiple contexts
2. Evaluate a type definition at one time and use the evaluation of the 
type at a later time

The change described  covers use case 2 at the cost of uncovering use 
case 1 and breaking existing build files.  A much similar solution would 
be to provide a mechanism for a datatype to be evaluation at an 
arbitrary time and be reused later and leave references for reusing the 
definition in multiple contexts.   For example, you could introduce an 
<evaluate> task that forces the evaluation of a datatype and saves it to 
a symbolic name.  At a later time, you could use the appropriate 
datatype element with a "use" attribute to "use" the earlier evaluation.

    <target name="init">
          <property name="src" value="./src"/>
          <evaluate to="initial_java_src">
                <fileset dir="${src}" includes="**/*.java"/>
      <target name="codegen" depends="init">....</target>
      <target name="copy_initial_java_src" depends="codegen">
            <copy todir="${build.dir}/initial_src">
                    <fileset use="initial_java_src"/>

That would still let you use:

        <fileset id="java_files" dir="${src.dir}" includes="**/*.java"/>

        <target name="compile" depends="codegen">
                <!--  evaluates fileset now, should compile files 
generated in codegen, not
                              just those that existed at start of 
project.    -->
                        <fileset ref="java_files"/>

When you just wanted to repeat boilerplate.

Defining an namespace for Ant 2.0 and using "xmlns" instead of 
"version", makes Ant behave much better in a mixed namespace document. 
 For example, if you used xmlns, then you could embed an Ant build file 
an XHTML document and have XSLT pretty print the Ant build file for you. 
 If you did not namespace qualify Ant 2 Elements, then <project> would 
be assumed to be an XHTML element and should cause the document to be 

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

View raw message