Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <451CFCF4.7010904@apache.org>
Date: Fri, 29 Sep 2006 12:01:08 +0100
From: Steve Loughran <stevel@apache.org>
User-Agent: Thunderbird 1.5.0.7 (X11/20060909)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: Resource.getURL() - example
References: <010301c6e31b$e191aac0$0301a8c0@julia>
In-Reply-To: <010301c6e31b$e191aac0$0301a8c0@julia>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stephen McConnell wrote:
>  
> 
>> -----Original Message-----
>> From: Scott Stirling [mailto:scottstirling@gmail.com] 
> 
> [snip]
> 
>>>> 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).
>> What you have in the [above] 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.
> 
> The generalization here makes me feel a touch REST-less as the scope of
> concerns are significantly different.  The paper deals with the www as the
> initial blackboard whereas the examples provided here focus primarily with
> normalization within the confines of a single physical hardware device
> within a context of a specific language API.  In effect the Java language
> via the protocol handler framework provides an important extension point.
> DPML's collection of protocols are (in the context of this discussion)
> nothing more than an example of the application of that API in dealing with
> basic development and runtime issues in larger scale project scenarios.
> This difference in scope an example that demonstrates an area where existing
> protocols and software are insufficient.


If you look at 1060research.com's NetKernel (disclaimer; friends of 
mine, its an ex-HPLabs project), you can see what loosely coupled REST 
designs can do in-process. Netkernel is an XML processing 
language/runtime that uses URIs extensively to refer to other things in 
the app, be they database selects, remote web pages, invocations of 
other functions, and then uses caching to decide which to re-evaluate 
versus serve up.

to do this they've had to build everything from the ground up, and have 
a nice (but complex) arch to do it.

If we retrofit stuff into Java, with Java URL handling, then some URL 
like a reference to a file on the classpath, it would have to be turned 
into a string that included a classloader reference:

classpathresource://classloader/03455he/resource/org/example/something

To turn it into a URL that represented the infinite random stream of a 
seeded random number generator, loaded as an antlib, I would be scared 
to think where to begin.

Yet I do know how to have an Ant resource to  do this

<ex:random length="412" seed="28" />

I can also imagine Ivy references fitting in here

<ivy:artifact project="org.apache.log4j" artifact="log4j" 
version="1.2.13" />

Or even the output of an pipe hooked up to the output of a running java 
program

<pipe:output refid="running.junit" />

I dont see that URLs fit in well to all these things.

My plans @ work post-ant1.7 would be to resource-enable our ant tasks so 
that we could feed the output of stuff into wherever resources are used, 
e.g

  <sf:resolved "HOST 192.168.2.1:console:main:iconized" />

to get back whatever resolve to the path console:main:iconized on a 
remote host.

Seems to me that there is a lot of fun to be had with Resource without 
worrying too much about REST-enabling ant's core.

Who else is doing stuff with resources?


> 
>>>> The key thing is that these protocols enable the removal 
>>>> of location concerns by shifting the focus to identity.
>> Another take on the [above] 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 
> 
> When we look at an individual codebase (and I'm referring here to a single
> codebase delivering a small number of discrete deliverables) the usage of
> location information (relative files locations and selection patterns) is
> totally appropriate. However, when codebase A references content in codebase
> B via location we are introducing a dependency not only on a foreign
> codebase location, but more importantly we are adding information about a
> foreign build strategy (via paths into a foreign structure).  If you
> consider a scenario where you are working with 10s or 100s of projects - the
> usage of explicit location (and the implicit leaking of foreign build
> strategies into the consuming project has (in my experience) been a major
> source of failure and contributes dramatically to build system maintenance
> overhead.  At the end of the day the movement towards identity versus
> locality is an example of the application of 'inversion of control'
> principals in that an individual build (or runtime) solution should not need
> to know where something comes from (which is a management concern) but
> instead should deal with identifying the things it needs.
> 
>> inside of a protocol handler black's box.
> 
> I would agree that protocol handling is an area of the JVM API a less well
> known (but I would disagree with the black-box metaphor).  In the context of
> this thread a protocol handler is simply a standard factory for standard
> connections.  The clarity of the behaviour of the respective protocol
> handler is directly related to its implementation and documentation.
> 
>> 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 (yet).
> 
> From my point of view the support for the association of a resource with a
> configured URL opens up some significant opportunities for down-scaling
> management applications (and here I am thinking specifically about products
> such as the Depot build-system).  The downscaling would be possible simply
> as a result of the use of common data elements - specifically URL instances
> that could flow in bother directions (from Depot to ant during project
> configuration, and from Ant to Depot during project execution).  
> 
> URL protocol handlers are simple standard structures and support within Ant
> for these structures would have a significant positive impact on the forward
> development of Depot.
> 
> Cheers, Steve.
> 
> --------------------------
> Stephen McConnell
> mailto:mcconnell@dpml.net
> http://www.dpml.net
>  
> 
>> Scott Stirling
>> Framingham, MA
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For 
>> additional commands, e-mail: dev-help@ant.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org