ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: New ANT task coding guideline
Date Sun, 30 May 2010 18:27:28 GMT
On 27/05/2010 2:04 AM, wrote:
> Please have a look at
> Maybe that could help.

But he still has a call to the setter even if it is autoconfed.

Note that setting spawn and resultproperty are mutually exclusive. If 
you spawn a process you can never get its result. I'd therefore suggest 
you separate this into two macrodefs. The spawning exec macrodef would 
be straightforward, the other might work if you did this:

<macrodef name="call-process">
<attribute name="resultproperty" default="false"/>
<local name="result" />
<condition property="result" value="@{resultproperty}" >
<equals arg1="@{resultproperty}" arg2="false" casesensitive="false" />
<equals arg1="@{resultproperty}" arg2="off" casesensitive="false" />
<equals arg1="@{resultproperty}" arg2="no" casesensitive="false" />
<exec spawn="false" resultproperty="result" failonerror="false" ...>

Note that you can't use <isfalse> for the condition because it is the 
negation of <istrue> rather than dealing with the false values directly. 
This means that passing "test-property" to resultproperty would leave 
the value unset. Checking for false values with equals solves the problem.

I haven't tested this to be sure it works, but if it works then so far 
as I can see the only side effect should be that you can no longer spawn 
with this macrodef because the setter on resultproperty sets a flag that 
says spawning isn't possible. So long as you can separate spawning 
processes from non-spawning processes in your build, I think this might 
solve your problem.

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

View raw message