Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <3.0.6.32.20001215122952.00b80bd0@latcs2.cs.latrobe.edu.au>
Date: Fri, 15 Dec 2000 12:29:52 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: AntEater
In-Reply-To: <000d01c06612$15ed6da0$d314730a@dot.state.oh.us>
References: <3.0.6.32.20001215060525.0096be10@latcs2.cs.latrobe.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:09  14/12/00 -0500, you wrote:
>Thanks for the lengthy reply. You should really post this mail and some
design
>docs into CVS. 

Probably ;)

>If you really want a cure for insomnia, look at the source for
>myrmidon and try to figure out what its purpose/intent is. ;-) Even after
>reading this post, I am not much closer to understanding your proposal.

unfortunately you need to be at least passing familiar with patterns used
in Avalon :/

>I may also be a bit backwards in my thinking, but I think most successful
>projects (opensource or otherwise) have a clearly stated purpose and
direction.

agreed.

>I think the current version of Ant is a very capable, elegant, and easy to
learn
>*build* tool. I would like to see Ant remain a *build* tool. IMHO, task-based
>execution is what Ant is about and what it should remain consistent with.

What the user see will be a clearly defined simple build tool. I actually
intend to write a XSLT sheet across the top of it to simplify it even more.
The reason being that most of the people I have converter to Ant are
web-develoeprs rather than programmers - thus not always comfortabkle with
structure of ant.

>If you can shoehorn different domains into this model then that is great,
but it
>seems like you are advocating the generalization of the current build model.

Why think small when you can think big? 

>While this can be a powerful paradigm, it can also dillute the
effectiveness of
>Ant's original goal, "Ant is a Java based build tool.".

Nope - the users don't care what the backend is - it could be written in
perl or c and it wouldn't effect the users besides the few who write tasks.
The taskwriters job will actually be simplified by clearly deliminating
responsibilities. One of the reasons why EJB/Servlet type specs are
successful - they incorporate the same patterns (ie Inversion of Control
and Seperation of Concerns) but do it at a coarser level.

>I also recognize that most projects like this often do not think beyond their
>intended design. I believe that you custodians of Ant have decided that it is
>time for Ant to break out of its box, and I welcome that. 

no one else but me and one other has expressed this but I hope there are
others out there who share my vision ;)

>Ant needs to be more
>integration friendly. I would personally like to see:

agreed.

>1. a stable Project-Target-Task object hierarchy (although these should
really
>be defined interfaces, not classes).

done in mymidon and will soon be done in AntEater

>2. an effective design to support the reading *and* writing of these classes.

again - both proposals cover this ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*