ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 03:37:47 GMT
At 06:25  13/11/00 -0800, you wrote:
>However, Ant doesn't. Therefore, it would not use the
>DocumentBuilder, but the SAXParser class, whereby it
>would ignore the goo it didn't need and build up the
>data structure in its own optimized way. Furthermore,
>the Project, Target, Tasks, etc. classes would have
>nice friendly accessor methods like
>Project.getTasks(), Target.getDependencies(), that
>may, or may not just delegate the work to the
>implemented org.w3c.dom.Node methods (an
>implementation detail that's irrelevant to this design
>discussion). Therefore in the Ant code you could do
>something like this:


>BuildFile f = new BuildFile("build.xml");


I would much prefer

>Project p = ProjectFactory.parse(f);

>Target defTarget = p.getDefaultTarget();

Would it be just better to return a string. This allows the project to
control a lot more about targets and especially allow for some of the
features that people want (like logic in if/else tags).


>No DOMness exposed. And assuming that ProjectFactory
>is sufficiently elegant, the classes are only as
>"heavy" as neccessary.


>There is an argument for having no implementation of
>the DOM interfaces, and requiring the GUI to delegate
>from a DOM structure to the Ant datamodel, but that is
>where I am right now, and I'm having to essentially
>reimplement the whole data model to do that. My
>argument is that if the Ant data model object
>implement the Element interface, then a lot of power
>can be derived from it.

I am not sure it is necessary to implement the element interface. Thou it
may be advantegrous for a GUI I don't see it as a desirable attribute for
general usage. It may be a PITA to reimplement DOM wrappers but the pay off
is that you get prebiult toolkits to work with them (Merlin). However if
you just want to use a DOM-like representation then you can look at in Avalon  and JDOM. Currently I run an ant-like system
using Configuration objects. It is ideal as the ant model of data is
identical to COnfiguration model of data.

>Editing is the primary reason. And in this discussion
>I don't think we should think of it as an "internal
>representation". That's what we have now. What we want
>is an API. There are probably many other reasons
>outside of editing that an external app may want to
>manipulate Ant's data model (e.g. implementing

right - I agree. I am currently using a bastard child of Ant to implement a
Cron-like job system. So you submit "cron" jobs as ant tasks. It will
eventually migrate to a few other places (namely Avalon, Cocoon and
hopefully Turbine and Jetspeed). 

>> Why not using SAX as the inter-module representation
>> of the build.
>As far as my understanting goes, SAX isn't a
>representation, but just a way of firing events in a
>serial manner when data/tokens of a certain type come
>along in the XML stream.

right. And you would have to implement a DOM-like system on top of that.



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message