ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve" <>
Subject RE: ComponentHelper replacement
Date Tue, 23 May 2006 18:28:35 GMT
Wolfgang Häfelinger wrote:

> Dominique Devienne wrote:
> > Ant's purpose is as a build tools, not a Java library.
> Perhaps time to change.

It seems to me that a primary objective of the Ant community has been to
focus on the build file XML integrity over and above API integrity.  If you
take the next step and attempt an abstract above the Ant API - e.g. a model
for a buildable project using ant as the build implementation - then Ant (as
a library dependency) is brittle.  However, it is possible to isolate Ant
idiosyncrasies as an implementation concern providing one can establish a
viable project model.

A viable project model introduces the following concerns:

  (a) resource management
  (b) dependency management 
  (c) project layout
  (d) build execution

None of the above are trivial concerns.  A resource management framework is
needed to address general resource of dependencies (jars, preference data,
deployment info, etc.) in a secure manner (where 'secure' can be asserted as
a system configuration concern -- i.e. it's not a case of saying that
something is signed or not - it's about enabling a controlled environment).
A dependency management model is needed to ensure integrity with respect to
the resources used and consumed by hundreds of projects with respect to
build, runtime and test phase dependecies.  The ability to construct and
manage project layouts is needed in order to support general simplification
of build procedures by adding an abstraction between physical file system
locations (dirs and files) from the tasks that deliver the ultimate value in
build process.  A build execution model is needed in order to create the
framework for generic processors that can extend/enhance common build
procedures without resorting to references to task names or local path

IMO - the above subjects are priority drivers for the evolution of the Ant
API.  In particular, these priorities focus attention on the following Ant
extension points:

  (a) ProjectHelper
  (b) ComponentHelper
  (c) PropertyHelper

As a general comment I've found these classes difficult to deal with and the
supporting documentation limited. My impression is that the codebase has
evolved with the intention of supporting third-party extension however in
practice my earlier comment concerning "brittle" comes to mind.  Given the
solutions out there I prefer Ant probably because of the working 'primary
objective' mentioned above -- however, I do believe that the community
dealing with Ant as a library needs to step up a take an assertive role in
the future direction of this project.

I.e. perhaps Dominique's suggestion on the money? 

Cheers, Steve.

Stephen McConnell

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

View raw message