ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Including other antfiles
Date Thu, 10 Aug 2000 18:13:29 GMT

Hmm... I think a change Stefan and I introduced a while ago is having some
unintended consequences.  This thread started in ant-user, but probably
needs to be resolved here first.

Originally, the ant task copied all the properties from the current project
into the new subproject during the call to Ant.init().  The drawback to
this method is if you have a large number of ant tasks (and I have
hundreds) you can run out of memory before your build even starts.  Barring
that, the effect was that any property in the original project was copied
into the new subproject _before_ the createProperty task is called, so if
the nested property elements have the same name they lose.

The change I suggested was to delay this copying of properties until the
ant task was exectued.  With some negotiation between Stefan, Conor, and I,
things were set up such that the subproject is created and available and
has the single task definition for the "property" task.  The createProperty
method could then safely call p1.createTask, and the nested property
element gets executed just before the subproject gets executed.  Everyone
is happy. (And thanks to Stefan for the improvements, and Conor for
pointing out something I missed in the original post.)

Only now, the nested properties in the ant task are overriding the ones
copied in from the original project.  Stepping through the code, it seems
that the properties are getting added at the right time, but the
ant/property elements are being treated as "user" properties, not "regular"
properties.  Since the "user" properties of the same name don't already
exists, they are added to the userProperties hashtable, and _copied_ into
the regular properties hastable overriding any existing definition.

Two questions.
1) What is the original intent of "user" properties?  I've never seen an
explaination of it.
2) Do we want to keep this new (and probably useful) behaviour, or go back
to the old behaviour?

Glenn McAllister
TID - Software Developer - VisualAge for Java
IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the
right answer to the wrong question." - John W. Tukey

Please respond to

Subject:        RE: Including other antfiles

--- Steve Sonntag <> wrote:
> One side effect of this behavior is that all properties are passed
> to subordinate ant files when one uses the ant task.  This means
> that it is a nice way to pass common properties to all subordinate
> ant files, but it also means that if there are properties that must be
> for each ant file that new names must be invented for the property in
> subordinate ant file because the property set in the superior ant file
> be overridden.

Um, no.  I thought this too (this is really a FAQ :-).

here's how you get around it(this is from my "Ant for Mortals" document --
I haven't released it yet; no, I don't know when I will; but yes, Real Soon
(let's assume this buildfile is called "this.xml")
<project name="adv_ant" default="common" basedir=".">
 <property name="first" value="bob"/>
 <property name="second" value="fred"/>
 <target name="common">
       <ant antfile="that.xml" dir="com/common">
               <property name="first" value="common"/>
               <property name="second" value="util"/>

The "first" and "second" properties are now overridden.  In fact, you could
modify the "ant" task to call the same buildfile!

  <target name="common">
       <ant antfile="this.xml" dir=".">
            <!-- calls this same buildfile, but new property values! -->
               <property name="first" value="common"/>
               <property name="second" value="util"/>

Do You Yahoo!?
Kick off your party with Yahoo! Invites.

View raw message