ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject RE: Resource.getURL()
Date Mon, 25 Sep 2006 18:53:00 GMT
--- Stephen McConnell <mcconnell@dpml.net> wrote:

>  
> 
> > -----Original Message-----
> > From: Dominique Devienne
> [mailto:ddevienne@gmail.com] 
> > 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:mcconnell@dpml.net
> http://www.dpml.net
>  
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message