ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject Re: Two issues
Date Thu, 22 Feb 2001 02:36:43 GMT

Properties in Ant are first-come, first-served. That's why command-line
defines override all others -- because they get there first. If there's no
command-line define, and there's a define in a <property> task in the
build-file outside of any target, then that's the one that wins.
Otherwise, the first target that gets executed that includes the setting
of that property is what it will be set to for the life of that running of
Ant. The only exception is by using either <antcall> or <ant> and
including a new value for the property(s). There is (currently) no way to
  <target name="foo">
    <property name="propA" value="A"/>
  <target name="bar">
    <property name="propA" value="B"/>
and have propA equal to A at one point and B at some other point in the
same run of Ant.


--- "Richard S. Hall" <> wrote:
> Tim Vernum wrote:
> > That's not quite the way it is though.
> > There is no parent/child relationship, there is just an order of
> execution.
> >
> > The "dependent" is actually executed first, (due to the nature of
> dependency)
> >  and therefore has first stab at the cherry. This is not a result of
> some
> >  "parent"/"child" relationship the way that
> >         commandline => parent-script => project => target
> >  works, it is just a result of persistence and immutability of
> properties.
> But, by definition, this is not caused by the order of execution, it is
> caused
> because the depending target is subordinate to the dependent target. 
> That is why
> my two targets that don't depend on each other (but have the same
> property
> ${}) each have their own value for that property, even if one is
> executed
> before the other.
> -> richard


Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices!

View raw message