Bruce Atherton wrote:
I think that would be very confusing at this point.
If most people in the ant community, especially committers, think that
this idea breaks the philosophy of ant, then it should not be developed.
Maybe this kind of needs will be better addressed using the new groovy
front-end. What I have in mind is the use of ant to drive deployments. I
think that although we state on the home page of ant that ant is a build
tool, because all batch processes, such as cooking or chemistry or
assembling a robot are also build processes in essence, ant can be used
to drive any process which is a sequence of tasks. If the process is
highly configurable, there can be several blocks of tasks which are
optionally executed.
For better or worse, Ant was designed from the beginning to build its
dependencies through backwards chaining. It is often (usually)
surprising behaviour to the first time user, but once learned quickly
becomes second nature. Introducing a new construct that does the
reverse seems likely only to cause massive confusion, especially one
with such a similar name.
What I propose does not set backward chaining in question. Another name
could be found. Instead of using a different attribute name "deep-if"
"deep-unless" one could use another element name such as <block,
<target-block, ..., for instance <block name="foo" depends="bar"
if="someproperty"/>.
The fact that often an init method is the lowest level dependency and
sets many of the properties used in "if" and "unless" attributes
higher in the dependency tree is, I think, a good way to introduce
people to the Ant way of designing builds as lists of target
dependencies.
Besides, as Jesse points out, there is a very simple workaround.
Using <ant/> or <antcall/> is not a perfect workaround.
ant and antcall create an ant subcontext. Properties and references set
by targets invoked through ant and antcall do not return to the calling
context.
also, targets which have already been executed when you reach <ant/> can
be executed a second time, and the targets which are executed during the
<ant/> invocation can be reexecuted later by the calling context.
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
