ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Ant allegedly becoming a perl
Date Tue, 11 Apr 2000 22:27:30 GMT

Craig McClanahan

>Wild idea:  One of the reasons I found myself using properties is that you
>cannot conveniently access the attributes of your surrounding object (i.e.
>tasks cannot see the attributes that were set on the <target> you are
>inside).  Conceptually, I suppose, you ought to be able to work your way
up the
>object tree to the <project> object.  Now, everything could be attributes
>instead of properties.  This is not too different from the environment
that JSP
>custom tags see at runtime, where you can work your way up a tree of
>page contexts.

I don't understand - probably a nomenclature thing.  I tend to thing of
members and properties as Java things and attributes as XML things.

I recently added the ability to have ids on any xml entity.  This is useful
for scripting as I not only gave scripts access to the entire "DOM" for the
Ant build definition, but I also pre-bound the variables to those nodes
before calling the script (much like is done in HTML on the client).

This has applicability outside of scripts.

If we split ant into an initialize phase and an execute phase, then a
parent project could easily override any arbitrary attribute of any named
XML element.  Something along the lines of:

         <override href="#id" name1="value1" name2="value2"/>

We could also allow any attribute to be set in this object based on the
value of any other attribute using something like

   <javac id="examples" destdir="../build/examples"/>
   <jar jarfile="examples.jar">
     <set attr="basedir" from="destdir" href="#examples">

I kinda like the first one, but I'm neutral on the last one.  A bit wordy.

- Sam Ruby

View raw message