ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Did somebody say Shut up and Write? :)
Date Thu, 21 Dec 2000 22:32:49 GMT
After all this discussion I guess I should put my point of view on the
No, I do not have a proposal coded, and I do not have a complete new
rearchitecture of ANT in mind, I did not see too much need for it. Although,
looking at some of the proposals I can see that there are quite a few
improvements that can be done.

Here is my vision:

ANT 2.0 I see as several collaborationg parts that when assemble together
produce a very good OS independent build tool. These parts however, and
maybe only to some extend are loosely coupled to one another, via APIs and
interfaces. These parts are:

1) Execution engine.
2) Tasks.
3) XML Language.
4) User interfaces.

1) Execution engine

Certaintly the basic functionality of ANT is its ability to execute
tasks and to follow and resolve dependencies. Whether we consider
projects as especialized tasks, or just targets as specialized tasks,
is not too relevant in principle. I would advocate however for having an
engine that knows as little as possible about tasks as we can do.

Another aspect I consider part of the engine is its ability of 
creating an internal representation (what we call today a project) out
of some XML "inspired" source format. No user, nor other of the loosely
defined components should need to know, nor rely on the engine internal

Differences with ANT 1.x:

- In ANT 1.x the engine, knows about certain tasks that have particular
priviledges, like being allowed outside <target>s. This makes very difficult
to extend the model or modified in the future.

- I believe the current <script> capabilities of ANT 1.x are misguided since
it allows direct manipulation of the internal representation of the engine.
This means that users have access and knowledge of the internal
representation of the projects, whch makes very difficult the evolution
of the engine in the future. I would argue that ANT 2.0 should not allow
or discurage such manipulations.

- I do not think that the GUI nor any other tool should have tight bound
access to the internal representation. Nor the internal representation
should be slanted to support this or that GUI approach. A Java IDE may know
about packages and classes, but it certaintly does not allow users access to
the class file internal representation. An IDE may have the ability to
manipulate the syntactic tree of the language it is specialized for, but do
not manipulate the compiled code produced out of the syntactic elements.

2) Tasks

Tasks are what make ANT, ANT. This is the most important contribution of ANT
and where users investmentments may be most affected when changes happened.
I would argue that ANT 2.0 should keep as much as possible the same
definition of Task as in ANT 1.x. ANTs Task API should be the most solid
and stable part of ANT.

ANT 2.0 should provide a well balanced predefined set of Tasks providing all
the basic functionality required for building complex Java based projects
which may require the execution of applications beyond what is offered as
part of the JDK.

ANT 2.0 sould provide the ability to add new sets of tasks, packaged
together as well as the ability to declare individual tasks.

Differences with ANT 1.x:

- We need to define a good set of CORE tasks to be shipped with ANT which
are stable and whose stability is promissed to be maintained. This as
opposed to the curret kitchen-sink approach of having all kinds of tasks
shipped and
maintained by Jakarta-ANT.

- Provide a way to declare and used prepackage Task sets, which Jakarta-ANT
or some other group may define for some set of common build process: EJB
deployment, for example. 

3) XML Language:

On the user front-end ANT builds are represented as XML. The source or
any preprocessing of the XML (XSLT, CSS, etc) is irrelevant with respect to
the ANT engine is concerned. 

XML is the visible/manageable representation of ANT projects. Tools may
interact with the XML representation. Other tools may preprocess the XML
representation in order to apply user configuration and other stylistic

The important point is that Users abstraction on what a build is and how to
manipulate it or change it is this XML view. Whether this XML view is seen
as text, DOM, JDOM or some other arbitraty representation convertible to XML
is irrelevant.

Differences with ANT 1.x:

- It makes clear what the user model of ANT is and what is not. This lives
free range to ANT to evelve independently of any IDE or other environment
tools may be using.

4)User interfaces

ANT 2.0 should provide a CLI interface as will as other interfaces GUI that
can be developed independently. Nor the CLI interface nor other tools
should have a priviledge access to ANT internals. They all should be at the
same level to validate that we are providing the correct functionality.

ANT should be user interface agnostic. Concepts like Workspace, and so on,
in my opinion relate to the user-experience and GUI usability, they belong
on the GUI tool but not on ANT. User-configuration (CSS, for example) may be
associated to a project by a GUI thru the definition of a workspace, but it
should not be a concept manipulated by ANT.

Difference with ANT 1.x:

- In ANT 1.x the CLI interface and the project building process are together
as one intermingled code. Some of the proposals try to bring the ANT model
closer to a particular GUI view of the world, looking at concepts like
workspace, or sharing nodes between ANT and the GUI tool.

- I do not think ANT should be slanted to some particular idea of how an
interactive tool organizes its building process. That deveates ANT from its
major objective which is to be effecient and useful on building Java based
projects from ANY environment (including those without a GUI), and
maintaining the portability of the build files across environments.


Well this are some on my thoughts. As you can see I have concentrated on
what I want ANT to be from the feature set and not on how it does it.
However, I think that it is very important the we prvide backward
conpatibility, as much as possible, not only at the XML level, but also at
the Task level. We need to preserve the investment people have made on ANT.


Jose Alberto

View raw message