> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 September 2006 4:58 PM
> To: 'Ant Developers List'
> Subject: RE: Resource.getURL()
>
>
>
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, 27 September 2006 2:00 PM
> > To: [email protected]
> > 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.
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:[EMAIL PROTECTED]
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
