ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: Antcall and undefined parameters
Date Mon, 09 Dec 2002 15:31:00 GMT
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}"/>

 <target name="xml"

<target name="xml-uptodate?" >
  <uptodate property="xml-updodate"
            targetfile="${alpha.output}" />

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 [] 
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:   <>
For additional commands, e-mail: <>

View raw message