ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: "parsed" resource
Date Fri, 29 Jan 2010 20:25:46 GMT

On Jan 28, 2010, at 11:19 PM, Stefan Bodewig wrote:

> On 2010-01-28, Matt Benson <> 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.

Nice solution--I thought Peter had submitted a BZ report with a patch  
for macroing types, but I can't find it now.  I had forgotten about  
resourcelist, but it does look like what you've proposed is a capable  
solution, and gives us the ability to do what I've suggested without  
having to create anything new.

>> 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.

Yeah, quite... although I think you've identified a--I hesitate to  
say "critical", but... "indisputable"--shortcoming in the current  
PropertyResource implementation in light of the recent PropertyHelper  
changes.  I have to concede that it is perfectly reasonable to  
expect, given PropertyHelper's ability to resolve arbitrary Objects,  
that such a resolved property ought to transparently behave as the  
parsed Resource, including name and all other properties.  I will  
code this ASAP and commit when I finish or after 1.8.0 is released,  
whichever is later.  While I do think this behavior is a reasonable  
expectation once a user has thought of it, I wouldn't necessarily  
call it the most obvious think either, so another solution might  
still be in order.

> 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)}"/>

Your paragraph says <resources> but your example uses <resource>; I'm  
going to assume you mean the latter.  <resource> is, of course,  
already available for using references.  A solution using this  
approach might be to make ResourceDecorator concrete, add a resource  
property setter for XML attribute accessibility, redefine a  
ResourceDecorator to, by default, refer to itself and call super  
method implementations, and replace the <resource> definition in  
types/ to point to ResourceDecorator instead of  
Resource.  This way I think we would be able to overload the  
<resource> XML element to accept a property parsed resource in  
addition to the refid and brute-force property setting attributes  
already allowed.  But such convoluted solution, though typical of me,  
I fear may elicit some controversy, so let the games begin!  ;)


> (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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message