Bug 22338 - add a "minversion" and a "version" attribute to taskdef
Summary: add a "minversion" and a "version" attribute to taskdef
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.5.3
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL: http://ant.apache.org/manual/CoreTask...
Depends on:
Reported: 2003-08-12 04:16 UTC by Ralf Hauser
Modified: 2008-11-24 03:57 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2003-08-12 04:16:28 UTC
different versions of an externally defined task may not all be suited for
building my project.

Since the external task I use also has a command-line interface, I first thought
to grab its version via "--version" exec call and then fail if I am not happy
with the output.
But as <condition> doesn't have a <greaterthan> and even that would be
cumbersome if the version numbering is something like 0.8.11, I suggest the
addition of two new attributes to taskdef in order to be able to ensure inside
the build.xml that appropriate versions of an external task are taken.

Therefore, a "minversion" attribute that ensures that at least a certain version
of the external task is used appears to be useful. The ant-execution could fail
if the specified version number or higher is not met. (I assume that such an
additional attribute would require the cooperation of the author of the external

Similarly, if the exact "version" is not availabe from an external task the
build would abort as well.

P.S.: One could try to do this with an <available> condition on the taskdef's
installation path, but even then, a) "non-cardinal" version numbering is likely
to make this cumbersome, b) some external tasks simply have a jar copied into
$ANT_HOME/lib and c) it appears to be good practice to access installations with
pathto/bin/programName/curr/bin/commandName with "curr" being a symbolic link to
a directory with the name of the version currently in production use.
Comment 1 Daniel Dekany 2003-08-12 11:24:28 UTC
It is not enough to check if there is greater-or-equal version available
than the version you have used originally with the project, because
software has sometimes non-backward compatible changes. So rather
something like this should be used:

<taskdef name="foo" classname="bar.Foo" compatible="1.4"/>

where "compatible" is an *arbitrary* string, and then Ant should define
a standard interface by which the external task can be invoked to check
if it is compatible. So the external task is who parses the version
number or whatever version description it gets with attribute
"compatible", not Ant, and it is the external task who judges if he is
compatible or not, not Ant.

But... I wonder how many external task developers would take the trouble
to maintain this stuff.