On Mon, 23 May 2005, Matt Benson [EMAIL PROTECTED] wrote:
So by that token, you would similarly add a Deletable
(?) interface for FileResource to implement. So then
move could fail when encountering a Resource that does
not implement Deletable...
Let's turn this around. Do we really want
On Mon, 23 May 2005, Matt Benson [EMAIL PROTECTED] wrote:
My proposal regarding copy is that any FileResource with a base
directory is processed according to BC,
+1
but any other Resource is copied with implicit flattening (and an
appropriate warning message) unless a nested mapper element
Now that ResourceCollections have been added to CVS, I
(and anyone who wants to help) need to add support for
ResourceCollections anywhere that it makes sense to do
so. As I have mentioned in some bugreps tasks that
operate on paths and should only get
real-filesystem-files should work by adding
Can it be - copy+delete in that case?
- Alexey.
Matt Benson wrote:
... Regarding the Move task, I don't see that we could
move non-file resources in a predictable way so I
would recommend failing on ResourceCollections that do
not return true from isFilesystemOnly().
Thoughts?
-Matt
--
--- Alexey N. Solofnenko [EMAIL PROTECTED]
wrote:
Can it be - copy+delete in that case?
Okay... here's what I did for preserving timestamps in
FileUtils copy methods. I added a Touchable interface
to the resources package. FileResource is (so far)
the only Resource that uses it, but I was
Sounds great. Do you have also Movable interface?
- Alexey.
On 5/23/05, Matt Benson [EMAIL PROTECTED] wrote:
--- Alexey N. Solofnenko [EMAIL PROTECTED]
wrote:
Can it be - copy+delete in that case?
Okay... here's what I did for preserving timestamps in
FileUtils copy methods. I added a
--- Alexey Solofnenko [EMAIL PROTECTED] wrote:
Sounds great. Do you have also Movable interface?
Not yet. Let's see if anyone else has anything to say
about these concepts too.
-Matt
- Alexey.
On 5/23/05, Matt Benson [EMAIL PROTECTED]
wrote:
--- Alexey N. Solofnenko [EMAIL
