On 2008-11-17, Nicolas Lalevée <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig a écrit :
>> On 2008-11-14, Nicolas Lalevée <[EMAIL PROTECTED]> wrote:
>>> But I see another solution, quite different. Probably most of the work
>>> should be done in the Resource class:
>> I thought about that, but Resource is already doing way too much IMHO.
> Well, in fact here you want a functionality to Resource (AFAIU).
No.
In the end what I want is a real decorator that attaches mapping on
top of an existing resource collection. Something that allows people
to write
<war ...
<mappedresource>
<path refid="some-path"/>
<chainedmapper>
<flattenmapper/>
<globmapper from="*" to="WEB-INF/lib/*"/>
</chainedmapper>
</mappedresource>
</war>
to package up all jars from nan arbitrary path into a WAR's lib
directory.
This really is pure decoration and not a functionality of the
resources involved.
> If you choose the former solution, then each time you want to add
> another implementation of Resource with some new capability, you will
> have to support it in MappedResource.
MappedResource now delegates on the as() (what is getAdapter() in
Eclipse) on to the decorated resource, no reason to support any of the
exiting interfaces.
> By the way, what about the Resource implementation in some ant
> plugins ? Is the Resource API exported ?
Yes.
> Wouldn't the former solution break some ant plugin ?
I lost track what "the former" was. I do expect that people are doing
instanceof checks on FileProvider (or more likely on FileResource -
but then we are out of luck anyway), that's why I kept the
FileProvider implementing subclass.
Appendable is new and the use cases I see for MappedResource make it
unlikely that you'd use it in a context where Touchable makes sense.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
