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.198 cause and error)
From: "Stephen McConnell" <mcconnell@dpml.net>
To: "'Ant Developers List'" <dev@ant.apache.org>
Subject: RE: Resource.getURL() - example
Date: Wed, 27 Sep 2006 17:44:06 +0930
Keywords: Business
Message-ID: <000901c6e20c$e791ba10$0301a8c0@julia>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <004b01c6e206$6b77eae0$0301a8c0@julia>
Thread-Index: Acbh8PXdBttT5dNlRFe4GeJPHAqsxAAEUx7gAAHwm6A=

 

> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@dpml.net] 
> Sent: Wednesday, 27 September 2006 4:58 PM
> To: 'Ant Developers List'
> Subject: RE: Resource.getURL()
> 
>  
> 
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: Wednesday, 27 September 2006 2:00 PM
> > To: dev@ant.apache.org
> > Subject: Re: Resource.getURL()
> > 
> > On Tue, 26 Sep 2006, Stephen McConnell <mcconnell@dpml.net> 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"/>
  </path>

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

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

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
detected.

Cheers, Steve.

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

--------------------------
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