Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: error (idunn.apache.osuosl.org: domain dpml.net from
 203.59.1.133 cause and error)
From: "Stephen McConnell" <mcconnell@dpml.net>
To: "'Ant Developers List'" <dev@ant.apache.org>
Subject: RE: Resource.getURL()
Date: Tue, 26 Sep 2006 03:37:08 +0930
Message-ID: <00a401c6e0cd$6abb86f0$0301a8c0@julia>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <255d8d690609250601q3392e955v35c8078285f0c219@mail.gmail.com>
Thread-Index: Acbgo66Wg5qs6VkuTcWu9b2bcW0MlAAH3MxQ

 

> -----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)
  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(). 

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