ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Possible bug in ResourceUtils and/or FileResource?
Date Sun, 12 Feb 2012 05:23:02 GMT
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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message