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 Thu, 28 Sep 2006 20:14:22 GMT
On 9/28/06, Stephen McConnell <> wrote:
> This difference in scope an example that demonstrates an area where existing
> protocols and software are insufficient.

OK, if you say so. In my experience the statement "existing protocols
and software are insufficient," is a red flag, but I will step aside.
I feel like I am ignorant of what's really going on in your builds.
I've worked some pretty hairy cross-repository builds in commercial
systems. I've never needed to resort to custom protocol handlers, so I
obviously don't know something about your situation that you do. Fair

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

I'm with you. I lost interest in Maven a long time ago because it was
obviously tailored for simple projects a la Jakarta commons projects.
I hear it's much better now, but anyway, I know the pain you're
talking about.

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

The common solution here is to establish some conventions and
contracts between projects, i.e., build A will output its artifacts to
location X, etc., build B will use location Y for its dependency

I don't see how custom protocol handlers, or much of anything, can
solve the maintenance overhead issue since you sound as if you have no
control over these distributed projects.

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

Well, I meant that to a new, e.g., release engineer coming onto a
project, he or she will be trying to understand the build(s). When he
or she can see how everything in the build is related via properties
files, shell scripts, and Ant build scripts (*declaratively*
programmed), then the principle of "least surprise" is met and the
person can probably figure this stuff out without me or you being
there, necessarily. And they can change stuff without dropping into

But when you encapsulate artifact location resolution into Java
protocol handlers (which is what I think you're doing), you've made
the build into something that, while, OK, not a black box, requires an
understanding of Java programming, which a lot of folks don't have or
don't think they should need to have (even when they do!) to undestand
how the build works.

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

I have to look into Depot. Like I said, I think I'll step aside and
let the discussion open up for others to give input.

Best regards,
Scott Stirling
Framingham, MA

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

View raw message