--- Stephen McConnell <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Dominique Devienne > [mailto:[EMAIL PROTECTED] > > Sent: Monday, 25 September 2006 10:32 PM > > To: Ant Developers List > > Subject: Re: Resource.getURL() > > > > > > The question is why would you need to get back > a URL from > > > > a Resource? > > > > > > You need to get a URL from a resource if you > want to use > > > the resource as InputSource in XML processing. > > > The URL is used to set the SystemId, in practice > to be able > > > to resolve includes, entities, ... which are to > be found > > > with a relative path. > > > > But when you get a StringResource, or > PropertyResource, which > > are ficticious Resource impls wrapping a string or > the value > > of an Ant property, even if you wrap these into a > custom URL, > > how would you resolve URLs relative to these??? > > > > This is the reason why I'm saying that a getURL > only makes > > sense for true URLResources only. > > > > Pushing it down to Resource smells wrong to me. > > I think the smell you are talking about may be the > general aroma related to > a class providing more than a single concern. The > Resource class as declared > in 1.6.5 addresses several: > > a) association with a name > b) comparable > c) equivalence > d) existence > e) association with a modification timestamp > f) association with a size > g) a flag declaring if the resource is a directory > > The version of Resource declared in 1.7 adds the > following additional > behaviour: > > d) streamable behaviour > a) a flag indicating if the resource is derived > from the filesystem > (which makes me uncomfortable)
FWIW, this probably would not be necessary except to ensure backward compatibility of the filesystem-based resource collections existing pre-Ant 1.7: fileset, dirset, path, filelist. Especially because it is an unfortunate fact that some tools, e.g. Sun's javac implementation (at least pre JDK 1.6), operate on files and not streams. > b) adds ResourceCollection as an implemented > interface > c) adds the ArchiveResource, CompressedResource, > FileResource, > JavaResource, PropertyResource, StringResource, > and > URLResource as derived types > > As things stand all of these classes expose the > operation getOutputStream(). > The getOutputStream() method is documented as > throwing > UnsupportedOperationException if the supply of a > resource stream is not > supported. IMO there is a good argument to include > getURL() at the same > level as getInputStream() and getOutputStream(). My > immediate conclusion is > that we could declare a interface named Streamable > that includes all three > methods and from this define the abstract class > StreamableResource. In > addition - any streamable resource implementation > should be required to > fully support getURL() and getOutputStream(). There are some situations in which it makes sense for a Resource to provide an InputStream but not an OutputStream. The examples that come to mind are for already set properties, and already "valued" strings. However, these both throw oata.types.resources.ImmutableResourceException in these cases, so I could live with the above proposal. But it probably needs to happen sooner rather than later, OR it could take the form of an intervening abstract class rather than an interface. Not sure if either approach promises any great benefit over the other here. -Matt > > Thoughts? > > Cheers, Steve. > > -------------------------- > Stephen McConnell > mailto:[EMAIL PROTECTED] > http://www.dpml.net > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
