ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <>
Subject RE: Resource.getURL() - example
Date Wed, 27 Sep 2006 08:14:06 GMT

> -----Original Message-----
> From: Stephen McConnell [] 
> Sent: Wednesday, 27 September 2006 4:58 PM
> To: 'Ant Developers List'
> Subject: RE: Resource.getURL()
> > -----Original Message-----
> > From: Stefan Bodewig []
> > Sent: Wednesday, 27 September 2006 2:00 PM
> > To:
> > Subject: Re: Resource.getURL()
> > 
> > On Tue, 26 Sep 2006, Stephen McConnell <> 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.

Here is an example of the hypothetical creation of path elements using
'artifact' as a foreign url resource handler.  The example presumes that the
usage of the 'uri' attribute triggers the creation of a new resource.

  <path id="foo">
    <resource name="widget" uri="artifact:jar:acme/widget"/>
    <resource name="gizmo" uri="artifact:jar:acme/gizmo"/>

In the following example I'm referencing existing named resources:

  <path id="foo">
    <resource refid="widget"/>
    <resource refid="gizmo"/>

In the creation (first) example I think the uri scheme is the key to
selection of a custom resource implementation class which is where something
like the implementation of an interface such as LocalFileProvider would be

Cheers, Steve.

p.s. the examples above use '<resource>' as a made up element.

Stephen McConnell

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message