ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject New ANT task coding guideline
Date Wed, 26 May 2010 15:03:30 GMT
I would like to propose a new ANT task coding guideline.  I frequently need to allow my users
to customize the ANT build via a file.  Therefore, a lot of my ANT task usage
has placeholders for the various different ant task attributes with variables, ${xxxx}.  The
problem is that many ANT tasks are written such that specifying an attribute with an empty
string has DIFFERENT behavior than not specifying that attribute at all.  I think this is
a problem.  That causes my code to have to use <if> statements to check if ${xxxx} is
set so that I can call the ANT task with or without the attribute specified.

Here is an example:

I wrote a macrodef called launchNative that would just call the <exec> task with optional
parameters for spawn and resultproperty.  They are optional since I defaulted their values
in the macrodef:

<attribute name="spawn" default="false"/>
<attribute name="resultproperty" default=""/>

In the actual call to <exec>, I had to put in the placeholders based on the parameters
of the macrodef like:

<exec spawn="@{spawn}" resultproperty="@{resultproperty}"/>

Now if the user passes in a macrodef parameter of spawn="true", the <exec> call will
fail even though resultproperty is defaulted to the empty string.  This is because the setter
for resultproperty in the <exec> ant task does NOT check the input resultproperty value
to detect the empty string and do nothing.  Instead it sets a flag stating it is not compatible
with spawn and the <exec> task eventually fails.

In order for me to get around this, I would have to use an <if> to check the value of
@{resultproperty} and call a separate invocation of <exec> without resultproperty specified.
 This is frustrating.

Therefore, I propose that a new ANT task coding guideline be introduced such that all setters
(where applicable) check the incoming values for null or empty strings and behave as if the
setter was never called.

Shawn Castrianni

This e-mail, including any attached files, may contain confidential and privileged information
for the sole use of the intended recipient.  Any review, use, distribution, or disclosure
by others is strictly prohibited.  If you are not the intended recipient (or authorized to
receive information for the intended recipient), please contact the sender by reply e-mail
and delete all copies of this message.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message