ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Cook" <>
Subject Re: Anteater... I'm Baaaack...
Date Wed, 06 Dec 2000 13:50:40 GMT
Is there a doc somewhere that discusses what Anteater is expected to become?
This is the first post I've seen (short time on list), and it seems that it is a
revolution/evolution of the current Ant product (1.2). I'm currently working on
Ant integration, and it seems like Anteater will have a greater emphasis on a
two-way core manipulation than the current product does, therefore minimizing
integration difficulties. But...will Anteater support current build scripts, and
what is a realistic timeframe for a workable beta and release.


----- Original Message -----
From: "James Duncan Davidson" <>
To: <>
Sent: Wednesday, December 06, 2000 3:36 AM
Subject: Anteater... I'm Baaaack...

> I'm back to the land of the net connected. :) 2 weeks playing in the Tropics
> was nice, but now it's time to get on with stuffs.
> So, I have just logged into my personal email for the first time since I've
> been back -- I *haven't* read anything that has happened on this list since
> 2 weeks ago, but I *have* checked in the AntEater sketch that was promised.
> I'll get to reading through the 700+ Ant messages that have stacked up in
> the next day or so.
> Note -- this is just a sketch. By no means is it a complete or even
> functional replacement to Ant yet as I spent time actually dinking with
> ideas and not with pulling over a bunch of code. That comes later. Its
> purposefully small so that the connections between the parts can be worked
> on without shaking everything else that would be there. Also note that this
> was hacked out on my MacOS X machine. It should work wherever, but I'm sure
> that I've accidentally put in dependencies on JDK 1.2.
> 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.
>   * 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.
>   * 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.
>   * AbstractTask is what actual Tasks extend. This has the functionality
>     of reflection et all. This is also where I'm thinking that the regexp
>     functionality should go (based on jakarta-regexp). What needs to happen
>     here of course is that the AbstractTask takes care of the regexp grunt
>     work and the task writer simply calls a method that says "does this
>     arg match that attrib?"
> How's it work:
> Well, since it's not yet a full ant, it can't even build itself.. There is
> however a bootstrap that is much more x-platform that the current
> boostraps...
>     cd anteater/bootstrap
>     javac
>     java Bootstrap
> And you'll see the following output...
>     [d-ucup02-124-247:proposal/anteater/bootstrap] duncan% java Bootstrap
>     Starting Bootstrap....
>     Making dir: ../bootstrap/temp
>     Making dir: ../bootstrap/temp/main
>     Making dir: ../bootstrap/temp/tasks
>     Making dir: ../bootstrap/temp/taskjars
>     Making dir: ../bootstrap/temp/tasks/copy
>     Making dir: ../bootstrap/temp/tasks/echo
>     Making dir: ../bootstrap/temp/tasks/jar
>     Making dir: ../bootstrap/temp/tasks/javac
>        Compiling 9 files to ../bootstrap/temp/main
>     Note: 2 files use or override a deprecated API.  Recompile with
>     "-deprecation" for details.
>     1 warning
>     Building copy
>     Building echo
>        Compiling 1 files to ../bootstrap/temp/tasks/echo
>        Copying ../source/coretasks/echo/
>     Jaring: ../bootstrap/temp/taskjars/echo.jar
>     Building jar
>     Building javac
>     -------------------------------------------
>     -------------------------------------------
>     Ant(Eater) -- Proposed Ant 2.0
>     Loaded Project: Ant
>     Dump of Project:
>         Target: main
>             Task: echo
>                 Att: data = Echo In Main
>         Target: default
>             Task: echo
>                 Att: data = Echo In Default
>     Executing Target: default
>     ECHOING: Echo In Default
>     -------------------------------------------
>     -------------------------------------------
>     Bootstrap Time: 6.3 seconds
> So, what this is -- the first chunk of output is the bootstrap code
> working... It then exec's a JVM that runs the real Ant (the "REAL" build)
> which then hits it's baby build.ant file (located in source/), reads it,
> dumps it the object model built from it, and then executes the default
> target -- which contains one task (the echo task). The Echo task is spitting
> out it's data attribute via the Project.out which is set to System.out by
> the CLI front end.
> Here's a bad sketch to help visualize:
>    CLI Layer <--> Ant Core / Object Model <--> Task Implementations
>            builds ->
>        configures ->
>       sets output ->
>  executes default ->
>                         loads up tasks
>                          crawls tree
>                         finds echo task
>                           executes echo -->
>                                                gets project.out
>                <-----------------------------  writes output
> More to come...
> .duncan
> --
> James Duncan Davidson                              
>                                                                   !try; do()

View raw message