ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject Re: Two issues
Date Wed, 21 Feb 2001 09:00:10 GMT

The <property> tag will not change the value of a property once it is set.

The motivation for this is to allow the build file user to override the
build file writer. For example, It would be annoying to have to edit a
build file to change the location of a build directory. In effect, this
creates the following hierarchy

command line -> parent build -> child build.

For example, if I want to build ant into a different distribution
directory, I could use
ant -Ddist.dir=/path/to/fubar

In the case of the antcall task, the parent build and the child build use
the same build file but are still distinct.

In Ant 1.x, the full set of properties from a parent build are set in the
child build, after any explicit properties are set (as <property> tags in
<ant> and <param> tags in <antcall>).

Whether you agree with this choice of hierarchy, it will not be changed in
Ant 1.x for backward compatibility reasons.

The fact that properties can be set in target scope, allows you to use
targets to control what value a property actually takes whilst still
allowing it to be overridden by the command line.


----- Original Message -----
From: "Richard S. Hall" <>
To: <>
Sent: Wednesday, February 21, 2001 6:00 PM
Subject: Re: Two issues

> Tim Vernum wrote:
> > OK, I'm not sure if I follow you correctly.
> > Each time I read it, I get a different view of what you are saying.
> >
> > In this case:
> >
> > <target name="A">
> >         <property name="prop" value="A"/>
> >         <echo message="${prop}"/>
> > </target>
> >
> > <target name="B" depends="A">
> >         <property name="prop" value="B"/>
> >         <echo message="${prop}"/>
> > </target>
> >
> > $ ant B
> >
> > should print
> >
> > A
> > A
> Yep, that's exactly correct.  It is not the bahavior I would expect.  The
> docs say that parent properties override child properties, I would not
> thought that in this case target A would be considered the parent of
> B.  But if that's the way it is supposed to work, then I will have to
> with it.
> -> richard

View raw message