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 Fri, 12 Jul 2002 13:00:07 GMT
Peter Donald wrote:

> At 11:20 PM 7/11/2002 -0500, you wrote:
>>> I thought the idea was that ant2 will have those famous incompatible 
>>> API/
>>> build.xml changes ( or will just be the next release after 1.9 :-).
>> Running existing Ant 1.x build files with Ant 2 could be implemented 
>> by a) recognizing the document is not using the Ant 2 namespace, b) 
>> piping the content through an XSLT processor.  No need to add a lot 
>> of code to support backward compatibility.  Hopefully, the syntax 
>> will be close enough that the transform would be fairly simple.  It 
>> would also give people a tool to convert an Ant 1.x build file to Ant 
>> 2 build file.
> That was the initial plan I believe. However in prototyping this it 
> was found that it was easier to add special code to handle the 
> differences. 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. 

That seems like a very undesirable change.  Referencing datatypes is 
primarily used to minimize boilerplate constructs and having a reference 
to a datatype mean something different than the same content expanded 
inline seems very undesirable.  That would mean resorting to entity 
expansion to use the same boilerplate constructs in different contexts.

> 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. 

I would think the easiest way would be to control the timing of the 
fileset evaluation by its placement in targets, but allow the result set 
from a previous evaluation to be used.  Maybe something like:

   <target name="init">
        <fileset dir="foo" includes="*.bar" saveAs="fooset"/>

    <target name="compileFoo1" depends="init">
               <fileset loadFrom="fooset"/>

> 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 -->
Assuming there are no other XML dialects in the world.  Having the Ant 
element namespace qualified would prevent an Ant project pretty printer 
from being misapplied to a freeway construction project or vice-versa. 
 Also, mixing unqualified elements with namespace qualified elements 
(which I believe were considered for extension tasks and types) is just 

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

View raw message