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.
jim ----- Original Message ----- From: "James Duncan Davidson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 Bootstrap.java > 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/taskdef.properties > Jaring: ../bootstrap/temp/taskjars/echo.jar > Building jar > Building javac > > ------------------------------------------- > STARTING REAL BUILD > ------------------------------------------- > > 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 > > ------------------------------------------- > FINISHED WITH REAL BUILD > ------------------------------------------- > > 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 [EMAIL PROTECTED] > !try; do() >
