ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 22338] New: - add a "minversion" and a "version" attribute to taskdef
Date Tue, 12 Aug 2003 04:16:29 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22338>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22338

add a "minversion" and a "version" attribute to taskdef

           Summary: add a "minversion" and a "version" attribute to taskdef
           Product: Ant
           Version: 1.5.3
          Platform: All
               URL: http://ant.apache.org/manual/CoreTasks/taskdef.html
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Core tasks
        AssignedTo: dev@ant.apache.org
        ReportedBy: hauser@acm.org


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

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message