ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Embedded Properties
Date Tue, 13 Apr 2004 20:09:32 GMT
On Apr 13, 2004, at 3:26 PM, Ivan Ivanov wrote:
> Hi Nick, Stefan and all we can do this also:
> <property name="Lib.Name.Static" value="foo"
> id="Lib.Name.Static"/>
> <property name="Lib.Name.Dynamic" value="bar"
> id="Lib.Name.Dynamic" />
> <property name="Lib.Name" refid="Lib.Name.${Type}" />
> BUT, the Holy Book[1] says it is bad :))

It does?  I had to go search for refid in the PDF to find what I said 
about it.  The full section is pasted below.  Yeah, I suppose I did say 
it is bad, but only because of what I thought of a better alternative 
to property swapping.  I would argue that for most cases, what folks 
really should use is the .properties file trick shown below, but having 
dynamically dereferenced properties is handy in some cases too.  I do, 
however, use the <propertycopy> task from ant-contrib, and now with 
Stefan's macrodef example, I'll likely switch to that.


Dereferencing properties
Makefile experts, and others desiring tricky variable dereferencing may 
be disappointed
to find that Ant does not have advanced evaluation of properties. They 
simply string substitutions and nesting properties does not accomplish 
what some
may expect. For example

   <property name="X" value="Y"/>
   <property name="Y" value="Z"/>
   <property name="A" value="${${X}}"/>
   <property name="B" value="$${${X}}"/> The “$$” is replaced by “$”
   <echo message="A = ${A}"/>
   <echo message="B = ${B}"/>

The output of the above is

   [echo] A = ${${X}}
   [echo] B = ${Y}

It is possible, however, to accomplish this, though rarely, if ever, 
would this particular
technique be needed in a build file. Make has a feature called 
“computed variable
names,” which is similar to our first attempts at dereferencing, yet 
with different
results. (In other words, A would have equaled Z.) Using an additional 
property is
required as a selector:

   <property name="X" value="Y" id="X.prop"/>
   <property name="Y" value="Z" id="Y.prop"/>
   <property name="selector" value="${X}"/>
   <property name="A" refid="${selector}.prop"/>
   <echo message="A = ${A}"/>

While this appears fairly straightforward, it is actually taking 
advantage of some fairly
complex capability of Ant, that of assigning an id to a task (in this 
case <property>).
The value of selector becomes Y, and the assignment of A uses the value
of the referenced “object” (in this case a task) by the name of Y.prop. 
Avoid this
kind of wackiness at almost all costs because there are much more 
standard and
clearer ways to choose a different set of properties, such as

   <property name="props" value="default"/>
   <property file="${props}.properties"/>

In this case, we load unless the property props has 
overridden previously, perhaps with

   ant -Dprops=my

This would load instead, thanks to property immutability 
and -D
setting props first.

NOTE There is a third-party task <propertycopy> provided at the 
ant-contrib project that more cleanly accomplishes property 
We recommend using this task instead of the craziness shown
here. See section 10.6 for details on <propertycopy>.

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

View raw message