--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > Sorry for dropping the ball. > Not a problem. To add another metaphor to the conversation, my plate's been so full lately I seem to be dropping various balls... ;)
> 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. Are you suggesting dynamic proxies here? I think this implicit RC mapping question does after all differ from Alexey's request; however I let myself misunderstand the direction of this thread and be led down the path of composing a large diatribe on THAT suject, which follows: Wrt explicitly mapped resourcecollections I think what is needed is a well-known syntax specification for specifying a string representation of [resource-type][String to pass to constructor] e.g. "file?/foo/bar.baz", "url?http://www.apache.org";, "string?blah blah blah". One may recall this as something I've been after for awhile--I consider it the "next step" for resource handling in Ant. For code compartmentalization we could probably add the code to generate a Resource from a String to ResourceUtils, but IH would know how to use e.g. RU.getResource(Project, String) to set Resource attributes (for BC, FileResource would be the default). This is to all intents and purposes the only way, IMHO, to seriously take advantage in Ant tasks of our early decision to design getOutputStream() into the Resource contract. You'll notice my use of the "?" character above to indicate the preceding text was the name of a currently available type. I used "?" because for xmlns as well as fs reasons I'm pretty sure this character should NOT be a colon. However I'm not sure what the RIGHT "trigger character" is and IMO this is the only outstanding question stopping us from adding this feature to Ant. Aside from allowing IH to transform a String into a given Resource, you'll see that tasks using mappers can choose to pass the mapped names to this same factory code and work with resources, or they can behave as normal and they will break if a user tries to map to an arbitrary resource type (assuming its string representation can't be misinterpreted as a file, a situation I hope we'll be able to prevent esp. by choosing the right "trigger character"). Back to our regularly scheduled content... > > > 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(). I think I knew that's what you meant... again, to implement MappedResource while remaining a FileResource, dynamic... subclasses? Eek! Surely we can't go there... maybe we'd better rethink the "instanceof FileResource" idiom instead, e.g. isFilesystemResource()? Fortunately Resource is a class instead of an interface which greatly increases our freedom. Then again, because Resource is a class we pretty much have no choice but to use dynamic subclasses if we must go this route. cglib dependencies, plus have you seen cglib? There's no javadoc--obviously the lib works but I certainly wasn't able to fathom it. But if we simply added isFilesystemResource() to Resource, couldn't a MappedResource just delegate to the original? Might that be enough? > > 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. I don't know. I don't think Resources were in extremely wide use until the 1.7 branch, and again, this is the type of problem that is extremely unlikely to simply arise at runtime--the build writer should have plenty of time to figure out "doh, <foo> doesn't seem to support X resource...". I think adequate disclaimers and warnings should suffice in these cases. -Matt > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
