On 2010-01-29, Matt Benson <[email protected]> wrote:
> On Jan 28, 2010, at 11:19 PM, Stefan Bodewig wrote:
>> 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 realized that myself when I looked through the code, I had completely
forgotten about that resource type until I looked for a way to implement
your parsedresource as part of an existing type.
> I will code this ASAP and commit when I finish or after 1.8.0 is
> released, whichever is later.
Great.
>> 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.
No, I really meant resource*s*
<resources add="${file(foo.txt)}"/>
This would be a resource collection whose sole element was taken from
expanding the property - much the same way your resource decoration
approach would work but without any decoration going on.
I don't think we have any tasks that accept a nested resource but not a
nested resource collection.
> <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 ...
No, then I'd rather see a "parsed" resource 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
