ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter reilly <>
Subject RE: Ant 1.6 local and macrodef attributes
Date Thu, 27 Nov 2003 18:33:01 GMT
Hi Jacob,
Most of this discussion is on the dev listing.
I can understand your confusion.

A brief history.
(You can search with keyword local at
to get the full gory details)

When macrodef was written originally, attributes
were (and are) implemented as textual substitution.
This was ok but they looked like normal properties
(using the ${x} notation). This caused a lot of
debate/confusion but I resisted changing the notation as I
do not like using different notation.

After using macrodefs for a little while I and other
people became aware that ant uses properties for
passing information between tasks and only having
non-mutable properties reduce the usefulness of
macrodefs a lot.

One can use ant-contrib's propertyregex and (via antelope)
var, and just overwrite properties - but this felt
like a big hack.

So one week-end I said what the heck and attempted to
implement local properties. It when through a number
of iterations.

When this was done, I realized that attributes could
be implemented by local properties and the problems
with notation would go away.

This interpretation of reality was not (to say the
least) universally accepted.

After the 1000'th e-mail explaining what was wrong
with this, I realized that there may be a point
in the argument.

So now there is two proposals:

1) to change the macrodef attribute notation from ${x}
   to @{x}.

2) add local properties - completely independent from
   macros - but can be used by them. (This is basically
   what the patch implements but without the @{x} notation)

The problem is that as these are serious changes to
ant internally (in the case of local) and externally
(new notation for attributes, properties seem not be non-mutable,
syntax of local), the changes need support from the ant committers.

As the local stuff is so new some would like to exercise it a
bit is 1.7 before committing to supporting for all time the
particular implementation and its public interfaces.


On Thu, 2003-11-27 at 17:50, Jacob Kjome wrote:
> At 07:03 AM 11/27/2003 -0600, you wrote:
> >The problem with this is that the property "file.available" cannot be 
> >redefined a second time now because the macrodef lives outside of any target
> >and so this property resides on top level.
> >
> >Is this essentially the problem you are facing?
> That is exactly the problem I am facing.
> >My answer would be that I am not opposing the use of <local> properties 
> >inside of macrodef calls anyway.  All that I am opposed to is implementing 
> >the <attribute> functionality with the same <local> mechanism.
> I always assumed that the attributes were local only to the macrodef 
> anyway.  I must have missed a bunch of the developer conversation.  What 
> purpose would <local> serve to an attribute that is already only in local 
> scope?  As far as I can tell, the current patch doesn't make <attribute>'s 
> global.  What does <local> have to do with <attribute>'s????  Man, I must

> really be missing something here.
> >  test.file is an <attribute>.  It is not a property of any kind, local or

> > otherwise.  If you want to say that any actual properties, defined within 
> > a call to a <macrodef>
> >either by invoking a target or directly are local, as the "file.available" 
> >property above, this garners no opposition from me.
> Well, that's a relief.  So, I guess I don't understand what all the 
> opposition is about then?  Can't we add <local> so that It works for tasks 
> that return actual properties and leave it at that?  You macrodef would 
> look like this...
> <macrodef name="A">
>     <attribute name="test.file"/>
>     <sequential>
>        <local name="file.available"/> <!-- this is the part that makes this

> macrodef non-useless. -->
>        <available property="file.available" value = "yes" file="@{test.file}"/>
>        <property name="file.available" value="no"/>
>        <echo>Is @{test.file} available? ${file.available}.</echo>
>     </sequential>
> </macrodef>
> ...
> <A test.file=""/>
> ...
> <A test.file=""/>
> I'm also not clear on the @{test.file} syntax.  I'm using ${test.file} and 
> it works just fine.  Actually, I just tried it and the @ syntax doesn't 
> currently work (having applied the <local> patch).  Is this what all the 
> hubbub is about?  If you are saying that you'd approve of the local patch 
> if it changed the syntax for accessing <attribute>'s to @{} 
> from ${}, then lets do it!  I don't care what the syntax is 
> for accessing <attribute>'s as long as I can use <local 
> name="someproperty"/> to keep  the property (not attribute, mind you) 
> "someproperty" resettable upon the next call to the same macrodef rather 
> than being set globally and, therefore, permanently the first time the 
> macrodef is called.  Like I've said before, without this functionality, the 
> above macrodef is totally useless.
> Is this doable or is there some technical issue standing in the way?
> Jake
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message