Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
To: ant-dev@jakarta.apache.org
Subject: Re: Anteater...  I'm Baaaack...
References: <B6533A9C.AD21%duncan@x180.net>
From: Stefan Bodewig <bodewig@apache.org>
Date: 14 Dec 2000 18:18:08 +0100
In-Reply-To: James Duncan Davidson's message of "Wed,
 06 Dec 2000 00:36:45 -0800"
Message-ID: <m3lmtiudkf.fsf@bodewig.bost.de>
Lines: 80
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Finally getting an hour or two to actually look at AntEater - and I'm
not sure when I'll have the next opportunity to do so.

Just like I did for Myrmidon I want to give some first comments. I'm
not going to compare the proposals ATM as I want to give you as well
as Pete the time to flesh out some things. 

James Duncan Davidson <duncan@x180.net> wrote:

> It should work wherever, but I'm sure that I've accidentally put in
> dependencies on JDK 1.2.

Think I've seen some File.getParentFile() calls 8-)

> What's here:
> 
>   * Taskpath functionality... Tasks are built into their own Jars
>     and loaded from those jars. The baby CLI interface takes a
>     -taskpath arg which is used to load up.

Yes.

I hope there will still be a a taskdef like functionality for tasks
that are not really worth a JAR of their own. One shot stuff that just
applies to a single use case in a single project.

What I really like is the idea of ...cli.Main to pull together the
classpath Ant needs and then start the actual build process from a
ClassLoader that contains all necessary classes. I know this is not
directly related to the Taskpath stuff, but it's very nice
nonetheless. Not cluttering environment variables - or forcing the
user to do so - is a good thing.

>   * Core Ant pulled away from CLI/GUI/Servlet -- these layers are
>     going to sit on top of what's currently there complete with an
>     Event system that hasn't been checked in yet. The CLI that is
>     there is just a shadow.  Next up is the listeners that report
>     things back to the Command Line.

I'm glad to hear that there will be an event system. I was about to
state how much I like our current BuildEvent system and how inferior
your AntFrontEnd approach was ...

So I'll wait for it to appear.

>   * Object model separate from Task implementation. The
>     Project/Target/Task tree is clear -- and is crawled at build
>     time. This allows any task to get ahold of it and modify it as
>     you go. It is a simple model, no more is there than needs to
>     be. I'm not yet sold either way on round- tripping.

No big surprises here, everything looks quite familiar. Can't wait to
see how/where you are going to store the information of nested
children.

>   * AbstractTask is what actual Tasks extend. This has the
>     functionality of reflection et all. 

I hope this is just a sketch as well 8-). We don't want to restrict
tasks on String type attributes again I hope. And a little caching of
reflection results could help as well.

And I really hope you don't forget data types like <path>, <fileset>
and so on, I think they deserve an abstract class to hold and reflect
the attributes - gee, why did you call Task Task? It can hold
attributes for data types as well and then move the reflection part
into something tasks and data types can share as well.

They'd need a Manager/Factory class like TaskManager as well.

>   This is also where I'm thinking that the regexp functionality
>   should go (based on jakarta-regexp).

What regexp functionality? Sorry, I can't follow you here.

One last thing. I don't think Project should take care of properties
at all. I'm still in favor of unifying properties with data types and
think they should be handled via some external store.

Stefan