On Wed, May 20, 2009 at 11:25 PM, Dave Pawson <dave.paw...@gmail.com> wrote:
> 2009/5/20 Dominique Devienne <ddevie...@gmail.com>:
>
>> I suggested postprocessing Ant's output as there are can hidden use of
>> properties which is not easy to pick up by parsing the Ant XML file
>> (they don't look like ${name} in attributes for example), and could
>> thus possibly pick up info on more properties.
>
>
> An example please Dominique?

XML elements reading properties without the ${name} notation
<target if/unless>
<fail if/unless>
<condition><isset property></condition>
...

XML elements writing properties affecting the rest of the build:
<condition property>
<exec (output|error)property>
<manifestclasspath property>
...

In macros with params having default params (or lack thereof, what you
try to catch), it uses @{name} to differentiate it from property using
the ${name}. Of course the two can be combined ${...@{bar}} so
figuring out what property could be missing would replicate the
running behavior.

These are various reasons looking for ${name} may be insufficient for
some builds. Nonetheless I agree than looking for ${name} covers a lot
of ground.

You need to watch out for property helpers though, as
${toString:some-ref-id} is a fake property name converting the Java
object (Ant datatype typically like a path) with reference id
"some-ref-id" to a string on the fly. (undocumented feature, but
there's an official API to add custom property helpers for
${helper:rest} notation.

> But yes, for clarity, I am assuming ${name} form. ?Best practice?

Using ${name} is how you deref properties in the XML. All I'm saying
is that property derefs happen in the code as well, and that even
${name} can have a different meaning with macros and property helpers
(the latter is not very common, but the former more so).

But as I said, ${name} covers 90% of the ground, if not more. I just
wanted to make you aware of the 10% or 5% or 1% you could be missing.
90+ % is a good hit rate ;-) --DD

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

Reply via email to