ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 16:16:37 GMT
At 07:40  14/11/00 -0800, you wrote:
>--- Peter Donald <> wrote:
>> At 06:41  14/11/00 -0800, you wrote:
>> Software Engineering 101 - Have the simplest
>> possible interface that can
>> represent what you need. 
>But Professor, what about leveraging existing
>standards and frameworks? ;-)

if they dont fit your needs and you are adding needless complexity then you
have fallen victim to flexability syndrome. You only reuse parts that make
sense and are appropriate for problem at hand. ie Dont place square blocks
in round holes ;)

>> Now do we need the functionality provided by Element
>> interface ? I would
>> say no to about 80% of it - and thus it is not
>> really a good idea to create
>> 80% new interface methods that will not be widely
>> used.
>The JDOM stuff looks very nice, and I think I
>understand where you are coming from with your
>argument. I admit that my proposal for extending
>org.w3c.dom.Element is only *one* option, and after
>thinking about what you said probably not the best
>one. I think I've so far been swayed by the idea of
>using the Element interface because there are other
>tools out there that know how to speak "w3c DOM", if
>you will. 

Are you talking about Merling - yer I would love to be able to use that but
oh well ;)

>I love to be able to leverage other's work,
>but in our case the so called "bloatedness" of the w3c
>framework may be too much.


>Since you pointed out that I've forgotten what I was
>taught in Software Engineering 101, I should admit
>that I forgot my SE 102 lessons as well; in my
>arguments I made the mistake of focusing on
>implementation rather than requirements. So let me
>step back and list the requirements I hope to have
>1) A navigatable tree structure that is faithful to
>the XML file structure.

>2) A common base class (other than Object) that the
>tree nodes inherit from for those cases where
>generality can be represented and common behavior
>gathered (like an abstract write() method and generic
>getParent() and getChildren() methods).

Not sure. I would question this requirement. I only see a need for Target
and Project objects and they have very little in common. Task objects
*should* (have to ???) be created at interpretation time and thus don't
exist in the tree. Only configuration data required to build them exists in
the tree in my vision of Ant2 ;)

>3) The ability to reconstruct the XML input, including
>comments, by appropriate traversal of the tree.

I see this as a side issue. It would be nice to allow a method to do this -
if it can be done cleanly ;)

>4) (The most GUI specific, but also useful for
>scripting) The ability to register
>PropertyChangeListener instances with the nodes to be
>informed of property changes.

I don't think this required as Target and Project attributes should not be
able to be altered and Task objects should not exist until it is reached

>> Well have a look at JDOM ( and
>Much nicer than w3c DOM!
>> Configuration interface in
>> Avalon project (
>Can you give me a package name? I briefly search
>through the CVSWeb and only ran into a configuration
>package with everything in the Attic. I'm very
>interested in learning more.

It is the Configuraiton interface in 

>> Configuration elements are a
>> 1-to-1 mapping with what Ant currently uses - JDOM
>> is a drastically
>> simplified DOM model that is performance sensitive
>> ;)
>I'm certainly interested in learning more from the
>lessons that Avalon has to offer. I'm sure duncan
>already has his ideas on how he wants to do things,
>but do you have some proposals you can make on how to
>meet the desires for a common data model?

I actually have a prototype working of what I want Ant2 to be. Currently it
is located in a machine not connected to network and as soon as I connect
to network again I was going to place it somewhere.
Basically it is seperated the following way 

Project interface (and default implementation)
Target interface (and default implementation)
ProjectBuilder (builds Projects from a input source - file/url)
DirectedGraph (Directed graph for dependency - also hopefully acylic)
Task interface (and AbstractTask)
TaskFactory (has definitions of tasks and can create them)
TaskConfigurer (takes a configuration and task instance and configures it)
Context - holds current data like current TaskFactory and property values.
Is hierarchial (ie can scope variables to local target or project scope)
and holds all "runtime" values and results. Paths and other data types are
just properties. It also has the current Logger instances stored in it.

Projects contain Targets. Targets contain Task Configuration elements. When
running Ant you execute a target and DirectedGraph picks the elements you
need to run etc. It then executes targets. Targets will pick up each
Configuration object (and each COnfiguration object represents a task). The
name of Configuration is passed to TaskFactory and an instance created.
Then Configuration is passed to TaskConfigurer which configures task. Task
is passed Context and configures itself (ie sets up logger and maybe nabbs
some properties). Then execute is called on task.

I also want (thou haven't done yet) a way to automagically validate the
parameters passed to ant tasks to make sure they conform to certain
patterns - not sure how to do this atm.

I designed it this way as I was mainly using it to build a Cron-like
system. I also wanted to allow for people who want to build installshield
type things. Basically all stuff below --- line in above is reusable. It
also provides nice interface to GUIS as you only deal with configuration
objects mainly.



| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device.      |

View raw message