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? [EMAIL PROTECTED]</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
[EMAIL PROTECTED] would be handled correctly by textual expansion. Someone please correct me if I'm wrong.
-----Original Message----- From: Jacob Kjome [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
