The 'canonical' Ant way to do what you what would be:
<target name="all">
<antcall target="xml" inheritAll="false">
<param name="xml.source" location="${alpha.source}"/>
<param name="xml.output" location="${alpha.output}"/>
</antcall>
...
</target>
<target name="xml"
depends="xml-uptodate?"
unless="xml-uptodate">
...
</target>
<target name="xml-uptodate?" >
<uptodate property="xml-updodate"
srcfile="${alpha.source}"
targetfile="${alpha.output}" />
</target>
which is very close to Benoit's second solution.
<antcall> 'opens' a new scope, so the property xml-uptodate potentially set
by the 'xml-uptodate?' target vanishes after the <antcall> 'returns', so the
next <antcall target="xml"/> is free to set it again.
As far as the if/unless counter-intuitive behavior, you're not the first one
to think such thoughts, but backward compatibility rules ;-)
I hope this helps. --DD
PS: Using inheritAll="false" is always a good idea...
-----Original Message-----
From: Eric Jain [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 8:26 AM
To: Benoit Voisin
Cc: ant-user
Subject: Re: Antcall and undefined parameters
> <condition property="xml.skip.istrue">
> <equals arg1="${xml.skip}" arg2="true"/>
> </condition>
> </target>
But wouldn't xml.skip.istrue only be set once? Anyways, ideally 'if' and
'unless' would consider any string of the form ${...} to be false, having
unset properties evaluate to true isn't exactly intuitive, in my opinion...
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
