Very often, a newer build file (even with version checking) using new tasks 
will fail at parse time, before you have a chance to really check for the 
proper version of Ant... --DD

That is sometimes true if the differences are related to actual tasks.

But many times the differences may come down to new or changed arguments on a 
command, an overly simple example being the addition of "if" and "unless" to 
<fail>.  Also, using an optional task such as <translate> does not fail under 
ant 1.4.1 (for example) until the time comes to execute the task.  Adding 
either of the two to a task in a buildfile and running it under ant 1.4.1 
executes the buildfile up to the point of actually attempting to run the task 
itself.  Any predecessor tasks _are_ executed.  

Previous comment last line should have read "predecessor targets" instead 
of "predecessor tasks".

One option discussed in the past would be specify a minimum_ant_version
attribute in the <project> declaration; if specified then we'd check for a min
version. Of couse, a new attribute would implicitly break all old versions...

With the capabilities of <condition> it would be rather simple to write the 
equivalent of a "minimal_ant_version".  And making the version information 
available as properties would still allow older ants to cleanly run and abort 
with a fully qualified message.

See the following example (please look only at the logic - I'm writing this out 
of my head and it may not be completely syntactically correct - and yes I know 
it will abort with ant 1.4.1 because of the <fail if>):


<project default="compile">
  <target name="checkversion-init" unless="ant.version.major">

    <condition property="ant.is.ok">
        ...
    </condition>  
  </target>

  <target name="checkversion" depends="checkversion-init" unless="ant.is.ok">
    <fail>
The version of ant you are using is not recent enough to execute this build.xml 
file.  You must use a version of ant that is at least 1.6.1.
    </fail>
  </target>


  <target name="init" depends="checkversion">
    ...
  </target>

  <target name="compile" depends="init">
     ...
  </target>

</project>

This should run as is (once the ... are filled in) even with ant older than 
1.4.1, and at least display the full text of the fail message.

This does point out that there would probably have to be enhancements made to 
the <condition> task to allow for inequality checking, as there doesn't 
currently seem to be a way to say

    if version.major = 1 then
        if version.minor >= 6 then
            if version.revision >= 1 then
                set ok
            else
                set error
            endif
        else
            set error
        endif
    else
        if version.major > 1 then
            set ok
        else
            set error
        end if    
    endif

A <version> test as part of <condition> might be very useful - a generic method 
for inequality checking of a dot-separated (probably should be configurable as 
to the separator) list of numbers.

For example:

  <condition property="within.range">
    <and>
      <version minimum="1.6.1" value="${ant.version.full}"/>
      <version maximum="1.6.3" value="${ant.version.full}"/>
    </and>
  <condition>

Try this

    <!-- set VERSION property -->
    <property resource="org/apache/tools/ant/version.txt"/>


      <condition property="ant141">
        <equals arg1="${VERSION}" arg2="1.4.1"/>
      </condition>

Not perfect but workable.

If that were incorporated into ant to create ${ant.version.string} (or whatever 
someone wanted to call it), and <condition> were extended as I suggested 
previously, that should be more than sufficient.  I'll try to supply a patch 
for ant.version.string at least - should be simple enough for a first-time 
contributor ;-)

Patch to expose ant.version.string.

Created attachment 3798 [details]
Patch to expose ant.version.string

made redundant via the antversion task of Ant 1.7.0