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 <bode...@apache.org> wrote:
> From: Stefan Bodewig <bode...@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
> <ddevie...@gmail.com>
> wrote:
>
> > On Fri, Sep 4, 2009 at 6:25 AM, <jan.mate...@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 ${...@{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-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
