You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2003/11/11 13:22:33 UTC
[VOTE] macrodef - do attributes as properties or substitutions
Hi,
I don't think that another discussion thread will lead us anywhere.
Instead of trying to summarize what has been discussed, let me point
to the archives (I hope the list is complete):
<http://marc.theaimsgroup.com/?t=106085269000002&r=1&w=2>
<http://marc.theaimsgroup.com/?t=106633643100003&r=1&w=2>
<http://marc.theaimsgroup.com/?t=106675058100005&r=1&w=2>
<http://marc.theaimsgroup.com/?t=106639175600004&r=1&w=2>
<http://marc.theaimsgroup.com/?t=106672947100005&r=1&w=2>
<http://marc.theaimsgroup.com/?t=106720903000001&r=1&w=2>
<http://marc.theaimsgroup.com/?t=106761809300003&r=1&w=2>
I'd like to keep this particular vote focussed on property versus
textual substitution. I am aware that the vote won't be complete
after that as we'll still have issues to decide upon (scope+extent or
notation, depending on this vote's outcome), but let's get this one
here straight first.
Actually, I'm not 100% sure about the rules we have to apply since
we've already shipped betas with the code, so strictly speaking a
decision we are considering a code change which would require (lazy)
consensus of the committers as opposed to a new idea that would
require a majority only. Let's see where we get from here and whether
we'll have to actually decide that at all 8-)
Stefan
OK, how do we want to implement <macrodef> attributes:
[ ] as textual substitution
[ ] as "real" Ant properties
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] macrodef - do attributes as properties or substitutions
Posted by peter reilly <pe...@corvil.com>.
On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement <macrodef> attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] local for 1.6
Posted by Steve Loughran <st...@iseran.com>.
peter reilly wrote:
> (hopefully this should be the final feature vote for 1.6)
>
> The local feature allows local properties - properties
> that are valid only for the enclosing scope.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942
>
> This is a useful feature in general and for macrodef in particular.
> For example the macrodef in Stefan's blog:
>
> http://stefanbodewig.blogger.de/20031114
>
> may be implemented by:
>
> <macrodef name="check-and-fail">
> <attribute name="class"/>
> <sequential>
> <local name="it-is-there"/>
> <available classname="${class}" property="it-is-there"/>
> <fail unless="it-is-there">Couldn't find ${class}</fail>
> </sequential>
> </macrodef>
>
> <check-and-fail class="org.example.Foo"/>
> <check-and-fail class="org.example.Bar"/>
>
> Vote:
> [ -0] local for ant 1.6
> [ +0] wait for ant 1.7
It would seem better to get this right before we ship, as then things
stay broken. Holding stuff over to 1.7 lets us experiment with the model
more before we actually ship. But I agree, without it, macrodef is more
limited.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: My itches with (was Re: [VOTE] local for 1.6)
Posted by peter reilly <pe...@corvil.com>.
On Wednesday 19 November 2003 09:46, Stefan Bodewig wrote:
> On Tue, 18 Nov 2003, peter reilly <pe...@corvil.com> wrote:
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> >> Your proposal uses a <local> task that sets up a local scope for a
> >> named property until the enclosing target/sequential finishes.
> >> Jose Alberto suggested to use a <local> TaskContainer instead,
> >> something like
> >
> > I think that this looks clumsy.
>
> possible - I'm not afraid of looking clumsy 8-) This is IMHO a case
> where verbosity is a win.
>
> > (note as well that local-property is not a valid name,
>
> Why not? Nothing's going to stop my from taskdeffing that name and
> <local> is a TaskContainer.
Correct, I just assumed that as local-property element only made sense in
your example as an nested element of the <local> and hense was a result of
an add/create<Name>() introspection method.
> Anyway, I'm in no way attached to any
> name, I would even be fine with <let> as the name of the container,
> but I'm afraid that not too many users would recognize this.
Or worst, too many users may recognize it...
>
> >> (2) Shadowing of properties
> >>
> >> I think they shouldn't be allowed to override any outer scope
> >> properties at all.
> >
> > I think that this will reduce their usefullness a lot.
>
> Maybe. It would be enough to isolate macrodef invocations from each
> other, though.
>
> Allowing them to override "plain" properties opens up the "properties
> are immutable" rule and makes it a "properties are immutable unless
> overridden in a <local>".
It does not (in my opinion) do this anymore that using <antcall>
with <param> nested elements.
<target name="docall">
<property name="x" value="global"/>
<antcall target="othertarget">
<param name="x" value="different value than '${x}'"/>
</antcall>
</target>
> This even stronger asking for a
> TaskContainer IMHO.
>
> What is your usecase for overriding properties?
Mysterious failures of macro's because some build file's use
a particular property name and others do not.
Normally people use short names for local variables - file, text etc.
They could be used at the different scopes.
Also recursive macrodefs would have a problem:
<macrodef name="recur">
<attribute name="number"/>
<sequential>
<localpropertycontainer>
<echo>number is @{number}</echo>
<localproperty name="mynumber"/>
<ac:math
datatype = "int"
result = "mynumber"
operand1 = "@{number}"
operation = "-"
operand2 = "1"
/>
<ac:if>
<ac:equals arg1="0" arg2="${mynumber}"/>
<ac:then>
<echo>Done</echo>
</ac:then>
<ac:else>
<recur number="${mynumber}"/>
</ac:else>
</ac:if>
</localpropertycontainer>
</sequential>
</macrodef>
(ok, maybe "localpropertycontainer" is a bit much)
>
> > The idea of not overridding user properties comes from the <ant>
> > family behaviour,
>
> Not only. Even setProperty will not override a use property.
Ok, the idea actually came for your previous e-mail pointing this out ....
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: My itches with (was Re: [VOTE] local for 1.6)
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 18 Nov 2003, peter reilly <pe...@corvil.com> wrote:
> On Tuesday 18 November 2003 15:53, peter reilly wrote:
>
>> me) more natural. However, I can see benefits ;- my code may not
> Opps that should of course be "the" code and not "my" code.
Don't worry 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: My itches with (was Re: [VOTE] local for 1.6)
Posted by peter reilly <pe...@corvil.com>.
On Tuesday 18 November 2003 15:53, peter reilly wrote:
> me) more natural. However, I can see benefits ;- my code may not
Opps that should of course be "the" code and not "my" code.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: My itches with (was Re: [VOTE] local for 1.6)
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 18 Nov 2003, peter reilly <pe...@corvil.com> wrote:
> On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
>> Your proposal uses a <local> task that sets up a local scope for a
>> named property until the enclosing target/sequential finishes.
>> Jose Alberto suggested to use a <local> TaskContainer instead,
>> something like
>
> I think that this looks clumsy.
possible - I'm not afraid of looking clumsy 8-) This is IMHO a case
where verbosity is a win.
> (note as well that local-property is not a valid name,
Why not? Nothing's going to stop my from taskdeffing that name and
<local> is a TaskContainer. Anyway, I'm in no way attached to any
name, I would even be fine with <let> as the name of the container,
but I'm afraid that not too many users would recognize this.
>> (2) Shadowing of properties
>>
>> I think they shouldn't be allowed to override any outer scope
>> properties at all.
>
> I think that this will reduce their usefullness a lot.
Maybe. It would be enough to isolate macrodef invocations from each
other, though.
Allowing them to override "plain" properties opens up the "properties
are immutable" rule and makes it a "properties are immutable unless
overridden in a <local>". This even stronger asking for a
TaskContainer IMHO.
What is your usecase for overriding properties?
> The idea of not overridding user properties comes from the <ant>
> family behaviour,
Not only. Even setProperty will not override a use property.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: My itches with (was Re: [VOTE] local for 1.6)
Posted by peter reilly <pe...@corvil.com>.
On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> On 18 Nov 2003, Stefan Bodewig <bo...@apache.org> wrote:
> > On Tue, 18 Nov 2003, peter reilly <pe...@corvil.com> wrote:
> >> Vote:
> >> [X] local for ant 1.6
> >> [ ] wait for ant 1.7
> >
> > and done right ;-)
Ouch ;-)
>
> Things we need to consider IMHO:
>
> (1) Syntax
>
> Your proposal uses a <local> task that sets up a local scope for a
> named property until the enclosing target/sequential finishes. Jose
> Alberto suggested to use a <local> TaskContainer instead, something
> like
>
> <local>
> <local-property name="...."/>
> </local>
>
> which would essentially just add an explicit (and differently named)
> <seqential> to your proposal. I think I prefer the more explicit,
> even if more verbose syntax of the second form.
I think that this looks clumsy. Making local's valid for the
current block scope (target level, or sequential level) feels (to
me) more natural. However, I can see benefits ;- my code may not
catch all uses of sequential.
(note as well that local-property is not a valid name, localproperty
would be correct).
> (2) Shadowing of properties
>
> Your updated proposal ensures that local properties do not override
> "global" user properties. I think they shouldn't be allowed to
> override any outer scope properties at all.
I think that this will reduce their usefullness a lot. The idea
of not overridding user properties comes from the <ant> family
behaviour, but they can overriden other properties.
>
> (3) Extent of local properties
>
> You make the local properties available to <script> - will they also
> be available for builds that get called with the <ant> family of tasks
> (assuming inheritall is true)? I think they should be.
Yes this is implemented.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
My itches with (was Re: [VOTE] local for 1.6)
Posted by Stefan Bodewig <bo...@apache.org>.
On 18 Nov 2003, Stefan Bodewig <bo...@apache.org> wrote:
> On Tue, 18 Nov 2003, peter reilly <pe...@corvil.com> wrote:
>
>> Vote:
>> [X] local for ant 1.6
>> [ ] wait for ant 1.7
>
> and done right ;-)
Things we need to consider IMHO:
(1) Syntax
Your proposal uses a <local> task that sets up a local scope for a
named property until the enclosing target/sequential finishes. Jose
Alberto suggested to use a <local> TaskContainer instead, something
like
<local>
<local-property name="...."/>
</local>
which would essentially just add an explicit (and differently named)
<seqential> to your proposal. I think I prefer the more explicit,
even if more verbose syntax of the second form.
(2) Shadowing of properties
Your updated proposal ensures that local properties do not override
"global" user properties. I think they shouldn't be allowed to
override any outer scope properties at all.
(3) Extent of local properties
You make the local properties available to <script> - will they also
be available for builds that get called with the <ant> family of tasks
(assuming inheritall is true)? I think they should be.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] local for 1.6
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 18 Nov 2003, peter reilly <pe...@corvil.com> wrote:
> Vote:
> [X] local for ant 1.6
> [ ] wait for ant 1.7
and done right ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] local for 1.6
Posted by peter reilly <pe...@corvil.com>.
(hopefully this should be the final feature vote for 1.6)
The local feature allows local properties - properties
that are valid only for the enclosing scope.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942
This is a useful feature in general and for macrodef in particular.
For example the macrodef in Stefan's blog:
http://stefanbodewig.blogger.de/20031114
may be implemented by:
<macrodef name="check-and-fail">
<attribute name="class"/>
<sequential>
<local name="it-is-there"/>
<available classname="${class}" property="it-is-there"/>
<fail unless="it-is-there">Couldn't find ${class}</fail>
</sequential>
</macrodef>
<check-and-fail class="org.example.Foo"/>
<check-and-fail class="org.example.Bar"/>
Vote:
[ ] local for ant 1.6
[ ] wait for ant 1.7
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] macrodef - do attributes as properties or substitutions
Posted by Gus Heck <gu...@cognition.olin.edu>.
My (non-committer) oppion coincides with Stefan here, with a slight
preference for
@{x}
because it looks like "put the substitution AT this location" when I
read it to myself.
However I can understand that $ escaping is already done and well tested
so reusing that code has value. $(x) is good enough for me if that is a
priorety (you will note I am not offering to code @{x} :) ).
(or we could make it (:x:) so that mozilla can turn them all into
smilies when we paste it to the list :) )
-Gus
Stefan Bodewig wrote:
>On Mon, 17 Nov 2003, peter reilly <pe...@corvil.com> wrote:
>
>
>
>>OK, how do we want to implement <macrodef> attributes:
>> current
>> [ ] as textual substitution ~ 4
>> [ ] as "real" Ant properties ~ 2
>>
>>undecided ~ 1
>>
>>
>
>only counting the "binding" votes would result in 1/2/1, so neither
>choice has received enough binding votes by now. Dominique, Jose
>Alberto and Steve know that I'm not ignoring their votes, but
>technically they are non-binding.
>
>
>
>>If macrodef attribute are to be implements as substitutions, what
>>should be the notation? (where x is the attribute name)
>>
>> [ ] as ${x} (look like ant properties)
>>
>>
>
>-1, too confusing.
>
>
>
>> [ ] as @x
>>
>>
>
>-1 doesn't work if you want to concatenate an expanded attribute and
>some other text, i.e.
>
><attribute name="foo"/>
><attribute name="foobar"/>
>
>is @foobarbaz the expansion of foo plus the literal text barbaz or is
>it the attribute foobar plus the literal text baz - or something
>completely different?
>
>
>
>> [ ] as ${attribute:x}
>>
>>
>
>-1 - still looks too much like a property and collides with existing
>properties that's name starts with "attribute:" (unlikely but
>possible).
>
>
>
>> [ ] as $(x)
>> [ ] as @{x}
>>
>>
>
>either one works for me - as well as {@x}.
>
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] macrodef - do attributes as properties or substitutions
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 17 Nov 2003, peter reilly <pe...@corvil.com> wrote:
> OK, how do we want to implement <macrodef> attributes:
> current
> [ ] as textual substitution ~ 4
> [ ] as "real" Ant properties ~ 2
>
> undecided ~ 1
only counting the "binding" votes would result in 1/2/1, so neither
choice has received enough binding votes by now. Dominique, Jose
Alberto and Steve know that I'm not ignoring their votes, but
technically they are non-binding.
> If macrodef attribute are to be implements as substitutions, what
> should be the notation? (where x is the attribute name)
>
> [ ] as ${x} (look like ant properties)
-1, too confusing.
> [ ] as @x
-1 doesn't work if you want to concatenate an expanded attribute and
some other text, i.e.
<attribute name="foo"/>
<attribute name="foobar"/>
is @foobarbaz the expansion of foo plus the literal text barbaz or is
it the attribute foobar plus the literal text baz - or something
completely different?
> [ ] as ${attribute:x}
-1 - still looks too much like a property and collides with existing
properties that's name starts with "attribute:" (unlikely but
possible).
> [ ] as $(x)
> [ ] as @{x}
either one works for me - as well as {@x}.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] macrodef - do attributes as properties or substitutions
Posted by peter reilly <pe...@corvil.com>.
OK, how do we want to implement <macrodef> attributes:
current
[ ] as textual substitution ~ 4
[ ] as "real" Ant properties ~ 2
undecided ~ 1
If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)
[ ] as ${x} (look like ant properties)
[ ] as $(x)
[ ] as @x
[ ] as ${attribute:x}
[ ] as @{x}
[ ] some thing else
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [VOTE] macrodef - do attributes as properties or substitutions
Posted by Stefan Bodewig <bo...@apache.org>.
> OK, how do we want to implement <macrodef> attributes:
>
> [X] as textual substitution
> [ ] as "real" Ant properties
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: [VOTE] macrodef - do attributes as properties or substitutions
Posted by Antoine Levy-Lambert <an...@antbuild.com>.
Sorry,
I would like to cancel my vote.
I am not too sure any more what is the right decision.
Cheers,
Antoine
-----Ursprungliche Nachricht-----
Von: Antoine Levy-Lambert [mailto:antoine@antbuild.com]
Gesendet: Dienstag, 11. November 2003 14:49
An: Ant Developers List
Betreff: AW: [VOTE] macrodef - do attributes as properties or
substitutions
On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement <macrodef> attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: [VOTE] macrodef - do attributes as properties or substitutions
Posted by Antoine Levy-Lambert <an...@antbuild.com>.
On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement <macrodef> attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org