It
looks like I will need to implement the <wizard>
local properties definition and the ant call model for <do>
sooner than I had intended. It turns out that the nature of immutable properties
runs very deep in the ant code. When most of the core tasks are first initialized
and run they resolve all of their properties, and if they are asked to initialize
again some jsut ignore the request. Change a property and re-run the task
and it doesnt take, because the propery value isn't supposed to change! (echo
and condition are two examples). I came across this trying
to implement the install type to components mapping, when selected one, saw
what was selected, went back and changed my decision. The radio buttons
regarding my selection were preserved, but the do section activating the
other properties executed the same as whatever my first selection was. Implementing
the nested properties will also need to entail a build listener that listens
to new property values that are applied to the project set of proeprties
as they are set, a simple antcall clones (in a circuitious but needed fashion)
the current build project and there is no passing back of the resultant propeties.
There are tricks that can be done to get those properties but they seem
too much to impose on the end user, it should be integrated and magically
work. The more I do this project the more I feel that
there is a significant impediance mis-match between ant and an installer. |
