ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: Ant 1.6 local and macrodef attributes
Date Thu, 27 Nov 2003 13:03:49 GMT

By "textual replacement" I mean essentially that a macrodef reference is expanded at the time
the file is read, more or less equivalently, time-wise, to how a C or C++ macro is expanded
by the preprocessor.  Attributes to such a macrodef are a completely different animal from
properties and their resolution takes place outside the property system altogether by a mechanism
that is only used by <macrodef>.

I'm trying to imagine your use case.  I think I understand what you are saying, but I may
not be.  It would be more helpful if you would provide an example, especially if the example
I am about to provide for you does not capture the use case you are describing.

I am supposing that you now may have something like this:

<target name="A">
  <available property="file.available" value = "yes" file="${test.file}"/>
  <property name="file.available" value="no"/>
  <echo>Is ${test.file} available? ${file.available}.</echo>
<antcall target="A" value=""/>
<antcall target="A" value=""/>

Converting to a macrodef would then be something like this, using the new syntax that is being

<macrodef name="A">
   <attribute name="test.file"/>
      <available property="file.available" value = "yes" file="@{test.file}"/>
      <property name="file.available" value="no"/>
      <echo>Is @{test.file} available? ${file.available}.</echo>
<A test.file=""/>
<A test.file=""/>

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?

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.  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.

-----Original Message-----
From:	Jacob Kjome []
Sent:	Wed 11/26/2003 11:35 PM
To:	Ant Users List
Subject:	RE: Ant 1.6 local and macrodef attributes
At 08:24 AM 11/26/2003 -0600, you wrote:
> >>we need some sort of local property functionality in order to
>make <macrodef> moderately useful.  If this is left out of Ant-1.6,
><macrodef> will be all but crippled and will hardly serve as an replacement
>for <antcall>.
>I don't understand this at all.  I think <macrodef> with textual 
>replacement (as opposed to local properties) will serve as a replacement 
>for very many of my current uses of <antcall>.  I can't really think of a 
>single one it won't serve for.

Please bring me up to speed on what "textual replacement" means?  If it 
provides the equivalent functionality to local properties, then 
whatever.  Call it whatever the heck you want.  Notice I have been saying 
"<local> functionality".  I don't care if the <local> patch or something 
else provides it and I don't care how it works.  I just want it to work.

And you "can't think of a single one"?  What about using existing ant tasks 
that store results in properties?  Are you saying that I should simply 
avoid using <pathconvert>, <available>, and all the other tasks that do 
this?  One call to a <macrodef> using these tasks will render it useless 
for the next call because the property won't be able to be overwritten once 
set.  Either I am missing something big here or you haven't taken more than 
a second to think about what you said above.  Please tell me I am missing 
something big and show me how to correct the situation; that is, being able 
to use <macrodef> with the mentioned tasks and have it work over multiple 
calls to the macrodef without using the <local> patch or something like it.

>To me <local> properties are a different issue.  I don't yet see what it 
>could do for me, but I haven't investigated it carefully enough and it no 
>doubt will prove very handy.  However, I see this as an separate issue 
>from <macrodef>.  There's a very good reason not to mix runtime expansion 
>of properties with loadtime expansion of macros - to do so makes a simple 
>paradigm vastly more complicated.

I'm not privy to how complex it might be, so I'll have to trust you that it 
makes it more complex.  However, I applied the <local> patch and it works 
great!  To me, as a user, it is exactly what I want and need.

>I believe there is a place for both, but it's not the SAME place.

Well, if <macrodef> doesn't support local properties (or whatever 
equivalent), then we're back to the same issue as before.  Macrodef is 
useless to me in the only two use-cases I have for it so far.


>-----Original Message-----
>From:   Jacob Kjome []
>Sent:   Wed 11/26/2003 7:56 AM
>To:     Ant Users List
>Subject:        Re: Ant 1.6 local and macrodef attributes
>Hi Stefan,
>I doubt many in the community are currently using <macrodef> so I'm not
>sure I'd point to lack of community support when saying whether or not to
>include <local> functionality in <macrodef>.  There are currently 6 votes
>for the <local> patch in Bugzilla.  See..
>My vote is one of them.  Whether the current patch or another one is
>decided upon, we need some sort of local property functionality in order to
>make <macrodef> moderately useful.  If this is left out of Ant-1.6,
><macrodef> will be all but crippled and will hardly serve as an replacement
>for <antcall>.
>I urge you and the other committers to either reconsider your votes for
>letting <local> into Ant-1.6 or come up with an equivalent (better)
>solution.  Either way, we need *a* solution that provides this
>functionality.  IMHO, you might as well remove <macrodef> from Ant-1.6 if
>you aren't going to allow for local properties.
>At 12:09 PM 11/26/2003 +0100, you wrote:
> >On Wed, 26 Nov 2003, peter reilly <> wrote:
> > > a)
> > > I sent a vote last week on local properties
> > > and the result was:
> > >                            committers  others (+ votes in bugzilla)
> > >    have local in ant 1.6   2           1 + 6
> > >    not                     0           0
> > >    +0                      1           0
> > >
> > > Based on this and other feedback I think that local does
> > > belong in ant 1.6.
> >
> >I agree with your opinion (that locals should be there, after all I'm
> >one of the two +1s), but disagree with the conclusion that this is
> >going to happen.  2 +1s is simply not enough to make a vote pass.
> >
> >I'm not trying to argue from a procedural standpoint but merely from
> >the fact that a change like this needs community support - and it
> >doesn't seem to have it.
> >
> > > b)
> > > I send an vote the week before about local properties being
> >
> >s/local properties/macrodef attributes/
> >
> > > implemented by textual replacement or by using local properties.
> > > The result was:
> > >
> > >                            committers  others
> > >    local properties        2           1
> > >    textual replacement     1           4
> > >    +0                      1           0
> > >
> > > I would like to implement attributes using local properties,
> >
> >-0.8
> >
> >most if not all things that could be done when we implement the
> >attributes as local properties are possible with textual expansion.
> >Textual expansion enables things that local properties don't.
> >
> > > I propose to commit local properties and implement attributes using
> > > local properties for the ant 1.6 beta3 release.
> >
> >-1 on both.  Both parts lack committer support.  We could try to
> >revote or something.
> >
> >Stefan
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message