Sorry for dropping the ball. On Tue, 6 Mar 2007, Matt Benson <[EMAIL PROTECTED]> wrote: > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> If you go that route, could you please extract the supporting >> methods into an interface that would allow other implementations to >> return ressources that change their names when used? Something >> like >> >> <mappedressource> >> <fileset refid="foo"/> >> <globmapper from="*.java" to="*.class"/> >> </mappedressource> >> >> which would return all files from the fileset and map the names of >> them (by returning Ressources that implement the new interface). > > This sounds like the feature Alexey has been demanding > all these years. ;) Possibly. But it is a bit tricky, I'm afraid. We would want to have a FileRessource remain a FileRessource even when mapping them - same for the other subclasses of Ressource. Some kind of factory would be needed and using an intferface instead of creating yet another subclass of Ressource (or a couple of them) might help. > But to do this with an interface means its consumers would have to > check for it explicitly; put another way, that all resource > consumers would not immediately benefit. If we implemented the > name-mapping behavior such that it simple overrode getName(), the > consequent question is why have an interface at all? The interface could provide access to the original name and override getName(). But before you dare to override getName, better check usage patterns in existing tasks. I wouldn't be surprised if we still had tasks that used "new File(parentDir, ressource.getName())" or something similar and expected the file to exist. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
