ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Mon, 05 Nov 2001 12:24:11 GMT
Jose Alberto Fernandez wrote:

> How committed are we to *all* this things? I really do not remember if there
> have been votes in all this details. 

Quoting from

"Ant2 will have a clear separation between the front-end that is 
responsible for user interactions, the object model that represents the 
project to build and the part of Ant that runs the build process itself. 
This separation is expected to ease the integration of Ant (or parts of 
it) into other products."

> The reason for my question is that I do remember
> the huge discussion we had about how AntGUIs were suppose to communicate with
> ANT itself (can they manipulate the build-model?) or should all communications
> be thru XML (either text or (J)DOM?). 

In my view, all front end processes will manipulate a build model - not 
DOM/JDOM/SAX or anything else XML specific. Some build models may ceom 
from non-XML sources including GUI models, embedded code, or whatever 
else you want to think of. XML representation is just one possible 

> Independently of what it is decided, I would like that any arquitecture we come up
> with will manage this "keyworkds" are its functionality in a pluggable fashion.
> That will allow for extensions or customizations in the future on this regard.
> I am not saying they are tasks, mayby they are ModelBuilders :)

The approach I outlined should support enough extensibility. I think we 
need to be careful not to overabstract the parser to cater for future 
possibilities that may never eventuate. Lets add it in when we really 
have a need.

> One thing that I would like to be able to do is for ANT to have a more reasonable
> implementation of <antcall>. Today every <antcall> reads and parses the project

> file over and over. 

Yep that is bad and doesn't work at all when the build model comes from 
a non-XML source. This will go, I am sure.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message