ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: How about ${fromRefId:some-reference}?
Date Fri, 04 Sep 2009 18:26:22 GMT
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 <bodewig@apache.org> wrote:

> From: Stefan Bodewig <bodewig@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
> <ddevienne@gmail.com>
> wrote:
> 
> > On Fri, Sep 4, 2009 at 6:25 AM, <Jan.Materne@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


Mime
View raw message