ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Stirling" <>
Subject Re: Resource.getURL() - example
Date Wed, 27 Sep 2006 13:40:05 GMT
On 9/27/06, Stephen McConnell <> wrote:
> > 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

The concept of REST
is coming to mind as I read this.

What you have in the next paragraph is very REST-ful in its way of
encoding location, version and name in URLs. I would ask us to
consider (Occam's Razor in hand) at what point one actully needs to
create a custom protocol (and code to support it) versus using
REST-ful URL conventions to achieve much of the same thing with
existing protocols and software.

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

Another take on the following statement is that location is a concern
to make explicit to the reader of a build script, rather than
obscuring a thing's actual location inside of a protocol handler
black's box.

> > The key thing is that these protocols enable the removal of
> > location concerns by shifting the focus to identity.

Just some thoughts on this interesting topic. I don't buy the need for
all these protocols and handlers or the associated flexibility in Ant

Scott Stirling
Framingham, MA

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

View raw message