From: "Peter Donald" <[EMAIL PROTECTED]>
> 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? 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="..." />
> 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>.
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.
> 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.
Jose Alberto
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
