> -----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: 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.
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]