ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Re: Anteater... I'm Baaaack...
Date Mon, 18 Dec 2000 05:13:59 GMT
On 12/14/00 9:18 AM, "Stefan Bodewig" <> 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-)

Yep. Well, I think we've turned the corner on that -- and that its going to
be damn useful to expose the data model as a Collection oriented tree --
especially for GUIs, so I'm not particularly worried.

> 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.

Yep -- that's easy. I was playing with the hard part first. :)

> 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.

:) Death to shell scripts.. At least complicated shell scripts. My dream is
to allow a user to have a executable that they can install in /usr/local/bin
that essentially is:

    java -jar ant.jar $*

>>   * 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.

Yep, the front end is a bit weak, but it's more in a direction that works.
More event styling is on its way.

>>   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.

To deal with regexp patterns in attributes. When a task allows regexp info
in an attribute/element, it should just be able to ask Ant to resolve it or
ask if 2 things match.

> 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.

Properties belong to a project. Whether they are strings or more
sophisticated Data types is are different.

James Duncan Davidson                              
                                                                  !try; do()

View raw message