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 2009/09/04 12:57:38 UTC
How about ${fromRefId:some-reference}?
Hi,
we have a PropertyEvaluator for ${toString:some-id} that looks up an
object with id "some-id" in the current project and expands to either
null (reference doesn't exist) or the result of calling toString() on
the object.
With trunk PropertyEvaluators can return non-Strings as values for
properties and IntrospectionHelper actually uses this. Say I have
public void setFoo(MyComplexType t)
as attribute and
<someTask foo="${property}"/>
and a PropertyEvaluator returns an instance of MyComplexType for
"property" then IntrospectionHelper will happily pass that instance
along (if the attribute setter didn't match the whole old
set-from-string logic would be applied to the toString() version of my
property).
This is most useful for tasks that want to accept Resource as an
attribute, all it takes is a property evaluator that returns a Resource
instance. For example
<http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/propertyhelpers.xml?view=log>
and
<http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/taskdefs/replace-test.xml?view=log>.
I suggest to add another core PropertyEvaluator that works like the one
for toString but doesn't invoke toString() on the reference (but leaves
that to IntrospectionHelper if necessary).
As usual, I'm unsure about the name of the prefix
${fromRefId:foo}
${ref:foo}
${refid:foo}
${fromReference:foo}
...
The ${ref:} and ${refid:} ideas look prettier but are more likely to
collide with existing property names.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: How about ${fromRefId:some-reference}?
Posted by Matt Benson <gu...@yahoo.com>.
You might also want to check out the refs and types evaluators from the props antlib here... they're a little generic though.
-Matt
--- On Fri, 9/4/09, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: Re: How about ${fromRefId:some-reference}?
> To: dev@ant.apache.org
> Date: Friday, September 4, 2009, 1:02 PM
> On 2009-09-04, Dominique Devienne
> <dd...@gmail.com>
> wrote:
>
> > On Fri, Sep 4, 2009 at 6:25 AM, <Ja...@rzf.fin-nrw.de>
> wrote:
> >>> I suggest to add another core
> PropertyEvaluator that works like the one
> >>> for toString but doesn't invoke toString() on
> the reference (but leaves
> >>> that to IntrospectionHelper if necessary).
>
> >>> The ${ref:} and ${refid:} ideas look prettier
> but are more likely to
> >>> collide with existing property names.
>
> >> Because you referencing an id I would prefer
> ${refid:*}.
>
> > Tasks in the past had to explicitly support this by
> adding a separate
> > attribute which typically (by convention) uses a "ref"
> suffix (classpath="...",
> > classpathref="..."), so having the following two
> notations
> > (classpathref="my_cp", classpath="${ref:my_cp}"
> equivalent leans
> > towards using ref:.
>
> That would only work if the setter inside the task would
> accept a Path
> argument.
>
> > We could avoid ambiguity by not using a ${}
> notation...
>
> Ahh, that's what I wanted to keep for a different thread,
> but now that
> you raise it ... see the thread I'm going to start next
> week ;-) [1]
>
> > I'm not sure I like the fact that ${} would start
> returning something
> > else than a String. Then there's
> classpath="foo${refid:my_cp}bar"...
> > When you mix literals and a reference, what happens?
>
> You get the same result that you'd get with
> classpath="foo${toString:my_cp}bar" today - that's how it
> is
> implemented, at least.
>
> > BTW, we already have ${} and @{} which interact in
> interesting ways,
> > allowing to do ${foo@{bar}} inside a macro. How would
> #{} (or ${refid:})
> > interact here?
>
> If we hook it into the PropertyHelper mechanisms (what I
> suggested) it
> will work just like any other property reference.
>
> > Sorry to raise concerns again...
>
> No reason to be sorry, that's why we discuss this stuff in
> the first
> place.
>
> Stefan
>
> [1] OK, I'd like to provide a String => Resource
> mechanism, something
> that has been discussed before. This is
> trivial for URLs, but we
> need something more generic. If we
> wanted to plug it into the
> PropertyHelper stuff (I haven't considered
> another option so far) it
> would probably be easier if we used or own
> PropertyExpander in order
> to allow something like #{url:${some.url}}.
>
> There are still a few things that I haven't
> thought through, so I'd
> like to defer that discussion for a few days,
> though.
>
> ---------------------------------------------------------------------
> 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: How about ${fromRefId:some-reference}?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-04, Dominique Devienne <dd...@gmail.com> wrote:
> On Fri, Sep 4, 2009 at 6:25 AM, <Ja...@rzf.fin-nrw.de> wrote:
>>> I suggest to add another core PropertyEvaluator that works like the one
>>> for toString but doesn't invoke toString() on the reference (but leaves
>>> that to IntrospectionHelper if necessary).
>>> The ${ref:} and ${refid:} ideas look prettier but are more likely to
>>> collide with existing property names.
>> Because you referencing an id I would prefer ${refid:*}.
> Tasks in the past had to explicitly support this by adding a separate
> attribute which typically (by convention) uses a "ref" suffix (classpath="...",
> classpathref="..."), so having the following two notations
> (classpathref="my_cp", classpath="${ref:my_cp}" equivalent leans
> towards using ref:.
That would only work if the setter inside the task would accept a Path
argument.
> We could avoid ambiguity by not using a ${} notation...
Ahh, that's what I wanted to keep for a different thread, but now that
you raise it ... see the thread I'm going to start next week ;-) [1]
> I'm not sure I like the fact that ${} would start returning something
> else than a String. Then there's classpath="foo${refid:my_cp}bar"...
> When you mix literals and a reference, what happens?
You get the same result that you'd get with
classpath="foo${toString:my_cp}bar" today - that's how it is
implemented, at least.
> BTW, we already have ${} and @{} which interact in interesting ways,
> allowing to do ${foo@{bar}} inside a macro. How would #{} (or ${refid:})
> interact here?
If we hook it into the PropertyHelper mechanisms (what I suggested) it
will work just like any other property reference.
> Sorry to raise concerns again...
No reason to be sorry, that's why we discuss this stuff in the first
place.
Stefan
[1] OK, I'd like to provide a String => Resource mechanism, something
that has been discussed before. This is trivial for URLs, but we
need something more generic. If we wanted to plug it into the
PropertyHelper stuff (I haven't considered another option so far) it
would probably be easier if we used or own PropertyExpander in order
to allow something like #{url:${some.url}}.
There are still a few things that I haven't thought through, so I'd
like to defer that discussion for a few days, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: How about ${fromRefId:some-reference}?
Posted by Dominique Devienne <dd...@gmail.com>.
On Fri, Sep 4, 2009 at 6:25 AM, <Ja...@rzf.fin-nrw.de> wrote:
>>I suggest to add another core PropertyEvaluator that works like the one
>>for toString but doesn't invoke toString() on the reference (but leaves
>>that to IntrospectionHelper if necessary).
>>
>>The ${ref:} and ${refid:} ideas look prettier but are more likely to
>>collide with existing property names.
>
> Because you referencing an id I would prefer ${refid:*}.
Tasks in the past had to explicitly support this by adding a separate
attribute which typically (by convention) uses a "ref" suffix (classpath="...",
classpathref="..."), so having the following two notations
(classpathref="my_cp", classpath="${ref:my_cp}" equivalent leans
towards using ref:.
OTOH, for addFoo() (i.e. nested elements), we use <classpath refid="my_cp"/>,
so that points towards refid:.
Either way is fine with me. classpath="${refid:my_cp}" reads well.
> There can be collisions as this is possible
> <project>
> <property name="x:foo" value="bar"/>
> <echoproperties prefix="x"/>
> </project>
>
> [echoproperties] x\:foo=bar
>
> but I think the ':' as seperation character is not a common use case.
> But in conclusion that would be a note in the "could break existing
> builds" section.
We could avoid ambiguity by not using a ${} notation...
I'm not sure I like the fact that ${} would start returning something
else than a String. Then there's classpath="foo${refid:my_cp}bar"...
When you mix literals and a reference, what happens?
I've always considered that expanding references should be
something part of the core, especially when writing all those
xyzref attributes in my own tasks.
Since references are introduced by using an id="abc" attribute,
and that such attributes in HTML are fragment which are accessed
using #abc in URLs, I'd prefer we introduce this notation to expand
references, rather than overloading ${}. #abc or #{abc}, the latter
being more consistent with our existing ${} and @{} notations.
BTW, we already have ${} and @{} which interact in interesting ways,
allowing to do ${foo@{bar}} inside a macro. How would #{} (or ${refid:})
interact here?
Sorry to raise concerns again... I'm just trying to see whether
reference expansion shouldn't be something built-in rather than
tacked on via PropertyHelper. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: How about ${fromRefId:some-reference}?
Posted by Ja...@rzf.fin-nrw.de.
>we have a PropertyEvaluator for ${toString:some-id} that looks up an
>object with id "some-id" in the current project and expands to either
>null (reference doesn't exist) or the result of calling toString() on
>the object.
>
>With trunk PropertyEvaluators can return non-Strings as values for
>properties and IntrospectionHelper actually uses this. Say I have
>
>public void setFoo(MyComplexType t)
>
>as attribute and
>
><someTask foo="${property}"/>
>
>and a PropertyEvaluator returns an instance of MyComplexType for
>"property" then IntrospectionHelper will happily pass that instance
>along (if the attribute setter didn't match the whole old
>set-from-string logic would be applied to the toString() version of my
>property).
>
>This is most useful for tasks that want to accept Resource as an
>attribute, all it takes is a property evaluator that returns a Resource
>instance. For example
><http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/
>propertyhelpers.xml?view=log>
>and
><http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/
>taskdefs/replace-test.xml?view=log>.
>
>I suggest to add another core PropertyEvaluator that works like the one
>for toString but doesn't invoke toString() on the reference (but leaves
>that to IntrospectionHelper if necessary).
>
>As usual, I'm unsure about the name of the prefix
>
>${fromRefId:foo}
>${ref:foo}
>${refid:foo}
>${fromReference:foo}
>
>...
>
>The ${ref:} and ${refid:} ideas look prettier but are more likely to
>collide with existing property names.
Because you referencing an id I would prefer ${refid:*}.
There can be collisions as this is possible
<project>
<property name="x:foo" value="bar"/>
<echoproperties prefix="x"/>
</project>
[echoproperties] x\:foo=bar
but I think the ':' as seperation character is not a common use case.
But in conclusion that would be a note in the "could break existing
builds" section.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: How about ${fromRefId:some-reference}?
Posted by Gilles Scokart <gs...@gmail.com>.
Altought it is not explicitely documented, the set of predefined properties
ant.* give the impression that ant. is a reserved prefix.
Maybe ${ant.ref:XXXX} would reduce the risk collisions
Gilles Scokart
2009/9/4 Stefan Bodewig <bo...@apache.org>
> Hi,
>
> we have a PropertyEvaluator for ${toString:some-id} that looks up an
> object with id "some-id" in the current project and expands to either
> null (reference doesn't exist) or the result of calling toString() on
> the object.
>
> With trunk PropertyEvaluators can return non-Strings as values for
> properties and IntrospectionHelper actually uses this. Say I have
>
> public void setFoo(MyComplexType t)
>
> as attribute and
>
> <someTask foo="${property}"/>
>
> and a PropertyEvaluator returns an instance of MyComplexType for
> "property" then IntrospectionHelper will happily pass that instance
> along (if the attribute setter didn't match the whole old
> set-from-string logic would be applied to the toString() version of my
> property).
>
> This is most useful for tasks that want to accept Resource as an
> attribute, all it takes is a property evaluator that returns a Resource
> instance. For example
> <
> http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/propertyhelpers.xml?view=log
> >
> and
> <
> http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/taskdefs/replace-test.xml?view=log
> >.
>
> I suggest to add another core PropertyEvaluator that works like the one
> for toString but doesn't invoke toString() on the reference (but leaves
> that to IntrospectionHelper if necessary).
>
> As usual, I'm unsure about the name of the prefix
>
> ${fromRefId:foo}
> ${ref:foo}
> ${refid:foo}
> ${fromReference:foo}
>
> ...
>
> The ${ref:} and ${refid:} ideas look prettier but are more likely to
> collide with existing property names.
>
> Stefan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: How about ${fromRefId:some-reference}?
Posted by Matt Benson <gu...@yahoo.com>.
--- On Thu, 9/17/09, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: Re: How about ${fromRefId:some-reference}?
> To: dev@ant.apache.org
> Date: Thursday, September 17, 2009, 11:07 PM
> On 2009-09-17, Matt Benson <gu...@yahoo.com>
> wrote:
>
> > So I take it you don't see any value in making all
> propertyhelper
> > delegates optional, as is the case with those provided
> by the props
> > antlib?
>
> To be honest, that thought never occured to me.
>
> > Or are you concerned about adoption, or...?
>
> If you could make the props antlib leave the sandbox and
> get released,
> that would probably help a lot 8-)
But how to release the cart (props) before the horse (1.8)? :)
-Matt
>
> 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: How about ${fromRefId:some-reference}?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-17, Matt Benson <gu...@yahoo.com> wrote:
> So I take it you don't see any value in making all propertyhelper
> delegates optional, as is the case with those provided by the props
> antlib?
To be honest, that thought never occured to me.
> Or are you concerned about adoption, or...?
If you could make the props antlib leave the sandbox and get released,
that would probably help a lot 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: How about ${fromRefId:some-reference}?
Posted by Matt Benson <gu...@yahoo.com>.
So I take it you don't see any value in making all propertyhelper delegates optional, as is the case with those provided by the props antlib? Or are you concerned about adoption, or...?
-Matt
--- On Thu, 9/17/09, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: Re: How about ${fromRefId:some-reference}?
> To: dev@ant.apache.org
> Date: Thursday, September 17, 2009, 7:04 AM
> On 2009-09-04, Stefan Bodewig <bo...@apache.org>
> wrote:
>
> > I suggest to add another core PropertyEvaluator that
> works like the one
> > for toString but doesn't invoke toString() on the
> reference (but leaves
> > that to IntrospectionHelper if necessary).
>
> It is in with svn revision 816153
>
> > As usual, I'm unsure about the name of the prefix
>
> Combining Gilles' and Jan's feedback it is
> ${ant.refid:foo}.
>
> Given that this property evaluator is the very first one
> added to
> PropertyHelper it will be the last one consulted.
> This reduces the
> possibility of collisions - if anybody used properties
> with
> ant.refid:foo in her build file, this file will work as
> before with
> current trunk. Only if a build file relied on
> ${ant.refid:foo} to not
> expand to anything and a reference named "foo" exists there
> will now be
> a change of behavior.
>
> 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: How about ${fromRefId:some-reference}?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-04, Stefan Bodewig <bo...@apache.org> wrote:
> I suggest to add another core PropertyEvaluator that works like the one
> for toString but doesn't invoke toString() on the reference (but leaves
> that to IntrospectionHelper if necessary).
It is in with svn revision 816153
> As usual, I'm unsure about the name of the prefix
Combining Gilles' and Jan's feedback it is ${ant.refid:foo}.
Given that this property evaluator is the very first one added to
PropertyHelper it will be the last one consulted. This reduces the
possibility of collisions - if anybody used properties with
ant.refid:foo in her build file, this file will work as before with
current trunk. Only if a build file relied on ${ant.refid:foo} to not
expand to anything and a reference named "foo" exists there will now be
a change of behavior.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org