Return-Path: 
 <dev-return-53301-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 84939 invoked from network); 29 Nov 2003 21:29:49 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 29 Nov 2003 21:29:49 -0000
Received: (qmail 82834 invoked by uid 500); 29 Nov 2003 21:29:36 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 82804 invoked by uid 500); 29 Nov 2003 21:29:35 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 81394 invoked from network); 29 Nov 2003 21:22:40 -0000
Message-Id: <5.2.1.1.0.20031129151337.028800b8@shell.visi.com>
X-Sender: hoju@shell.visi.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Sat, 29 Nov 2003 15:22:41 -0600
To: "Steve Cohen" <SCohen@sportvision.com>
From: Jacob Kjome <hoju@visi.com>
Subject: RE: Ant 1.6 local and macrodef attributes
Cc: <dev@ant.apache.org>,<hoju@visi.com>
In-Reply-To: <D466FBEAA19E7E408BE3FAAC6EEB56760504230A@utah.ignitemedia.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


Thanks for that Steve.  I really appreciate you going the extra mile to 
help out with a solution to this predicament.  If your example below 
actually works with Ant-1.6 final then, ugly or not, I'll be satisfied with 
the temporary solution and will patiently wait for a less hacky solution in 
Ant-1.7.

Can anyone verify that Steve's work around actually works?  When will the 
@{x} stuff be committed to the 1.6 branch (or is it already)?  I'd like to 
test it out ASAP.

Jake

At 10:20 AM 11/29/2003 -0600, Steve Cohen wrote:

><moving this discussion to ant dev list and including Jacob Kjome>
>
>Thanks, Jacob, for continuing to pursue this, and deepening my awareness 
>of the problem.
>
>I appreciate your dilemma, even though I still agree with what has become 
>consensus that textual substitution is right for <macrodef>.  The whole 
>business with the scope of properties is already complicated enough.  The 
><local> patch or something like it will be necessary to solve your use 
>case.  But is <local> the right thing?  Maybe we need to think more 
>generally (not, heaven forbid, for 1.6!!!) about tasks that return values 
>in properties and how these should be implemented in the context of macrodefs.
>
>The key point is that when such a property was called inside of an antcall 
>that created a property locally within the execution context of the 
><antcall> call.  Textual substitution destroys that.  A <macrodef> looks 
>like a separate execution context but is not, at least not as currently set up.
>
>Since that is unlikely to be resolved in time for 1.6, can we suggest a 
>workaround for the interim?
>
>I think we can.  It's a bit ugly, but it does allow us to replace 
>macrodefs calling tasks that return properties, even without <local>.  We 
>just add one level of indirection.
>
>Instead of this:
>
><macrodef name="A">
>    <attribute name="test.file"/>
>    <sequential>
>       <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="foo.bar"/>
>...
><A test.file="bar.food"/>
>
>where the problem is that the property "file.available" cannot be 
>redefined a second time now because the macrodef lives outside of any 
>target and this property therefore resides on top level
>
>we can instead do this:
>
><macrodef name="A2">
>    <attribute name="test.file"/>
>    <attribute name="available.prop"/>
>    <sequential>
>       <available property="@{available.prop}"
>                  value = "yes"
>                  file="@{test.file}"/>
>       <property name="@{available.prop}" value="no"/>
>       <echo>Is @{test.file} available? ${@{available.prop}}.</echo>
>    </sequential>
></macrodef>
>...
><A2 test.file="foo.bar" available.prop="foo.bar.available"/>
>...
><A2 test.file="bar.food" available.prop="peanuts.available"/>
>
>This is annoyingly less simple than <local> but still allows <macrodef> to 
>be used in 1.6 with tasks that return values in properties.  I am assuming that
>${@{available.prop}} would be handled correctly by textual 
>expansion.  Someone please correct me if I'm wrong.
>
>
>
>
>-----Original Message-----
>From:   Jacob Kjome [<mailto:hoju@visi.com>mailto:hoju@visi.com]
>Sent:   Fri 11/28/2003 6:39 PM
>To:     Ant Users List
>Cc:
>Subject:        RE: Ant 1.6 local and macrodef attributes
>
>Thanks for explaining that Peter.
>
>I took a look and found your latest proposal here...
><http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2>http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2
>
>Seems that Stefan liked it...
><http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2>http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2
>
>So, I guess that means that proposal #1 below is going to be implemented
>for Ant-1.6.  However, does this still leave <local> properties out to
>dry?  I'm totally fine with using @{x} syntax for attributes, but macrodef
>is still mostly useless to me unless I can do...
>
><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>
>
>
>Jake
>
>At 06:33 PM 11/27/2003 +0000, you wrote:
> >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
> ><http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2>http://marc.theaimsgroup 
> .com/?l=ant-dev&r=1&w=2
> >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.
> >
> >Peter
> >
> >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="foo.bar"/>
> > > ...
> > > <A test.file="bar.food"/>
> > >
> > >
> > > 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 @{attribute.name}
> > > from ${attribute.name}, 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org