ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Tue, 06 Nov 2001 04:24:00 GMT
On Tue, 6 Nov 2001 14:25, Jose Alberto Fernandez wrote:
> From: "Peter Donald" <>
> > On Tue, 6 Nov 2001 03:13, Jose Alberto Fernandez wrote:
> > > From: "Peter Donald" <>
> > >
> > > I do not know what you mean?
> > > Has <antcall> being -1 as user pattern?
> >
> > <antcall/> as a lightweight method call has been.
> Have you take a look at ANT's build.xml file later? It uses <antcall/>
> in several places, why are this uses acceptable if you claim such use
> has been rejected?

how many times do I have to state this. <antcall/> in ants own build file is 
used due to limitations of ant1.x. Several committers have stated that they 
dislike antcall for numerous reasons. The only committers who supported 
antcall are me and diane and I have changed my mind.

This is not the first time I have said this ... hmmm didn't I say this just 
last week in response to one of your other "questions".

> Maybe they are not considered "lightweight", but how do you plan to
> distinguish between "lightweight" and "not lighweight" usages?

we discourage use of antcall because it will not be a lightweight call.

> > > Otherwise, I do not see how a "use case" can be use to veto some
> > > particular implementation approach.
> >
> > easily. See java wrt to pointers.
> Please elaborate.

pointers lead to bad programming thus they were eliminated from the picture.

> Of course the question here is how close can the model and runtime
> representation be, and still maintain the ability to process this kind of
> thing efficiently. Today, the model (Project) and the runtime state are so
> close (almost the same) that cannot do any reuse. The other extreme would
> be to use JDOM/DOM as the model (memory equivalent to XML File) and process
> from there. Is there a more efficient intermediate state?

well the JDOM/DOM or TOM (Task Object Model) is basically the way that most 
of the proposals have done. The tasks are represented via TaskModel that is a 
simplified XML-like structure (basically elements can't have mixed content). 
Two of the the proposals also have Target and Project models that are not 
represented as this XML-like tree.

There is essentially 3 types of state that we should be modeling. How we do 
it is up to debate. They are;
1. property/datatype values 
2. list of registered tasks, aspects, conditions, datatypes, other types etc
3. targets that have been evaluated

(1) is accessible to projects tasks - probably via TaskContext

(2) is accessible to components inside runtime and two proposals have called 
this the "frame"

(3) IIRC is also stored in frame of one prposal while others just keep it in 
call stack. I prefer it to be stored in frame as that makes management of 
cross-project DAGs much simpler and a bit lower coupling.



   "Don't play dumb with me. 
I happen to be an expert at that" 
           - Maxwell Smart

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

View raw message