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 05:55:03 GMT

Ill answer these questions ... yet again. The answers are all in the archives 
though if you want further clarification and don't want to come off as 
trolling again - look em up.

On Tue, 6 Nov 2001 16:40, Jose Alberto Fernandez wrote:
> > 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.
> Does this mean that you are against <ant> also? 

no ones ever said that. Though come to think of it there will probably be a 
much lesser need for this task. Not sure.

> Unless you remove that one
> the exact same usage pattern can be achieved. Actually that is what the
> current implementation does:
>     <ant buildfile="${ant.file}" target="..." />

Well considering ant.file will probably not be a property in Ant2 it will 
look something like

<ant file="build.xml" target="..." />

but other than that yep.

> > 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".
> I certaintly doubt people will be willing to give up <antcall>.
> I have not seen the proposal for any other task that allows altering
> property values in a controlled manner. Which I think is a valid usage for
> <antcall>.

The need for this has slowly been decreasing. The majority of reasons that 
this is used nowadays is to implement dynamic templating which is not 
something that we will be supporting. 

It was used in the past a fair bit to get around limitations of declarations 
(ie when properties where used in path elements or like) but most of these 
limitations have been removed. I am not actually sure if there is any of 
these issues left ????

> But since you are so convinced, can you clarify how you forsee the new
> constructs you propose in ANT2 can be used to rewrite ANT's own build file?
> I am trying to understand what is what you have in mind.

templating. The same idea I have had since you convinced me how evil antcall 
was. See archives for description.

> > 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
> We should not forget the tasks objects attribute and element setting, which
> depend on the current state of property/datatype values.

we have already voted to have this evaluated at runtime so there is no need 
for any state recording as everything is either stored in (1) or the TOM. 
Nothing else is needed.



"When we remember we are all mad, the mysteries of life 
disappear and life stands explained." -Mark Twain

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

View raw message