ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Tool Integration Problems
Date Sat, 09 Dec 2000 01:53:52 GMT
At 05:17  8/12/00 -0800, Jose  Alberto Fernandez wrote:
>My point is, who needs this full dynamic configuration? Does ANT needs
>it for doing its job. Do the task implementation use it?
>If the answer is that it will be used only when some external (e.g., GUI)
>entity manipulates the representation, then I think we are bloating
>te core.

Nope it is used in and by the core. Externel tools will probably be able to
use it to read the configuration but will not be able to use to write to
the Task Object Model (TOM). A TOM is needed because without it we would be
forced to hack together things in a manner similar to UnresolvedElement
objects everywhere. This just iunifies all representation of tasks.

>The way I see it, ANTs core should just create a snapshot of the project
>from some external representation and execute the task indicated.


>The next time you manipulate wichever external representaton you have,
>ANT will just get a new snapshot and act on it.

agreed. Thou having hooks in it so that you can share the object model
between tools is good. The tool may extend the builder so that it creates
MutableConfiguration elements rather than Configuration elements thou ant
would be none-the wiser - because the interface wouldn't change for

This is best of both worlds with virtually no loss (a little more work for
GUI people but a lot less than if they had to rewrite it from scratch).

>I do not think we want ANT to be able to execute while in parallel we
>change the definition of what it needs to do. 


>If you agree, then the 
>question is why should the core support such dynamic configurability.

essentially so we can support interpretation at runtime in a clean and
consistent manner. Such as

<task1 attr="${myvar}" />

To do this now we actually do create a TOM - it is a little less flexable
and a little more bloated than the Configuration TOM and worse it is
inconsisitent with how the rest of the tasks work. 

Using a Configuration TOM allows all the flexability at little cost ... it
actually saves memory in the case of some large task classes. It slows down
execution a little but speeds up initialisation time ... but there is a lot
more things that we need to concentrate on that consume more CPU time
before we start optimizing this.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message