> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 September 2006 2:00 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
>
> > As such, some resource are implicitly file based (e.g.
> > FileResource) while other resources may (or may not) be
> > resolvable to a local file.
>
> What kind of resources would that be?
I make extensive use of custom protocols to represent links to resources not
contained within a particular project code-base. These protocols include
the following:
'artifact' used to resolve resources from a collection
of remote hosts (where the definition is 'remote'
is a configurable characteristic) based on group,
name, type and version data
'local' used to reference local preference information
using the same 'group', 'name', 'type' and
'version' pattern
'link' a symbolic reference that enables one group,
name, type, version reference to point to another
resource
All of these protocols include support for the establishment of a locally
cached file that is a copy of the remote resource (partly driven by the need
to handle the relationship between models of projects and Ant's build-time
requirements). Typically a link such as link:jar:acme/widget#1.2 (a
symbolic link defining a jar file under the group namespace acme, name
widget, with a published version of 1.2) could reference an artifact such as
'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a range of possible
sources where each source defines its own scheme for artifact to path
transformation (i.e. the automation of the transformation of the artifact
specification to something like
file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is an example of one
of potentially multiple source paths).
The key thing is that these protocols enable the removal of location
concerns by shifting the focus to identity. Supporting this principal is
the internal support for the maintenance of a local file cache which is used
for things like Ant where file paths are required.
> > The important distinction here is that Path should allow
> > any type of resource that is resolvable to a local file
> > (but which is not necessarily a file resource).
>
> I agree under the assumption that such resources exist.
>
> > However - there is nothing in the definition of Resource
> > that allows an implementation to return a local file.
> > Instead the current model assumes that only FileResource
> > is a valid source of a local file.
>
> Or the recommended extension point for custom resources that
> are resolvable to local files.
However - in practice the class is not an appropriate extension point as it
commences with the assumption that the resource is a file. In effect
URLResource is a better starting point in that the principal of initial
representation of identity and source of stream information is the url.
> > This could be resolved by separating the concern of local file
> > resolvability via a interface dedicated to this concern .. E.g.
> >
> > public interface LocalFileProvider
> > {
> > File getFile();
> > }
>
> Would work and it would even be pretty easy to retrofit the
> implementation of isFilesystemOnly to look after that
> interface instead of the FileResource class. Same for task
> that only work on FileResources right now.
That's my impression as well.
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
