ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <SCo...@sportvision.com>
Subject RE: Ant 1.6 local and macrodef attributes
Date Wed, 26 Nov 2003 14:24:25 GMT
>>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.

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 believe there is a place for both, but it's not the SAME place.


-----Original Message-----
From:	Jacob Kjome [mailto:hoju@visi.com]
Sent:	Wed 11/26/2003 7:56 AM
To:	Ant Users List
Cc:	
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..
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
http://issues.apache.org/bugzilla/showvotes.cgi?bug_id=23942

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.

Jake

At 12:09 PM 11/26/2003 +0100, you wrote:
>On Wed, 26 Nov 2003, peter reilly <peter.reilly@corvil.com> 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: user-unsubscribe@ant.apache.org
>For additional commands, e-mail: user-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org






Mime
View raw message