Hi,
Stefan Bodewig wrote:
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 ...)
What does ${file(foo.txt)} mean exactly ? Does this mean something like :
- create a file resource from the file "foo.txt" in the ant project base
directory, then read the file, and create a resource collection
containing files listed in the text of "foo.txt" ?
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. ;)
Maybe we can create a 1.8.1 in two or three months from now, and include
such new concepts as these decorated resources and also some bug fixes.
IIRC Antoine hinted he wanted to build 1.8.0 today, so it would be too
late anyway.
I am still planning to build 1.8.0 today
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
