On 2010-01-28, Matt Benson <gudnabr...@gmail.com> wrote:

> Okay, using custom PropertyEvaluators (e.g. the "types" evaluator from
> the props antlib) we can set an attribute of a task or type to  an
> arbitrary Ant type.  I would like to (after 1.8.0, I suppose) add  a
> resource implementation that simply allows one to say, e.g.:

> <parsedresource parse="${file(foo.txt)}" />

> Now, programmatically, this type is ridiculously trivial:

> public class ParsedResource extends ResourceDecorator {

>   public void setParse(Resource r) {
>     addConfigured(r);

If macrodef could be used to define types it could wrap around

<resourcelist>
  <string value="$${file(foo.txt)}"/>
</resourcelist>

as well.

> From a code perspective, this can be interpreted as simply
> implementing a means of specifying the decorated resource as a bean
> property, as an alternative to calling a method.  And the "parsed"
> mechanism only comes into play if the user consciously chooses to
> configure Ant's PropertyHelper appropriately.  So I'm searching for a
> better name for this concept.

You know I'm not really into names ...

My gut feeling is that there should be a way to do it with/by extending
a built-in resource rather creating a new one.  And then it occured to
me that the <property> resource would be a great fit.

Maybe it would be better (from a naming perspective) if you could do

<property name="file(foo.txt)"/>

instead.  I realize this would require bigger code changes.

The other idea I had was to add the functionality to the <resources>
resource collection, where the implementation would be as trivial as
shown in your code.

<resource add="${file(foo.txt)}"/>

(now add becomes the name to talk about ...)

> Finally, I'd be delighted if, once a nomenclature is settled upon, if
> the community said "hey, this is both trivial from a risk perspective
> yet potentially quite useful--let's include it in 1.8.0!", but I
> certainly won't insist upon it.  ;)

IIRC Antoine hinted he wanted to build 1.8.0 today, so it would be too
late anyway.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to