On 2012-02-10, Jeffrey E Care wrote: > Actually I may have spoken too soon when I said that just setting basedir > was a good fix. It was for one of my test scenarios but it wasn't enough > for a more complicated scenario. I still think something's not quite > right, though I think that the problem might extend into Copy as well - I > can't say for sure as I don't fully understand all of the logic within > Copy at the moment (it's much more complicated than I thought it would > be).
What I guess you see isn't only related to copy. Some tasks including copy bypass quite a few of the Resource methods if they can get hold of the File underlying it. In copy's case this is mostly so old File-based methods signatures could be kept for backwards compatibility. > My solution that works in all test scenarios has been to change the > inheritance tree on my custom resources, so it no longer extends > oata.types.resources.FileResource. Unfortunately that wasn't enough > either, so I had to drop implementing FileProvider. Once I drop > FileProvider everything works. That kind of sucks as really this resource > really should be an extension of FileResource, but the customization I > need is around the resource name and the way that FileResource handles > that just doesn't seem to work properly. I've had to resort to extending > Resource and re-implementing most of the same methods that FileResource > re-implements, and in the same way :-( Maybe an approach like the one of MappedResource could help you. MappedResource acts as decorator for a FileResource and passes everything through except getName() - and it explicitly prevents the resource from acting as a FileProvider so nobody can bypass the getName method. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
