ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy Lambert <>
Subject Re: deep-if/deep-unless
Date Wed, 16 Dec 2009 15:32:31 GMT
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" 
> 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 

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.



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

View raw message