ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: EasyAnt phases
Date Thu, 13 Nov 2008 19:28:51 GMT
2008/11/13 Stefan Bodewig <>:
> On 2008-11-12, Remie Bolte <> wrote:
>> Thanks for the explanation, it indeed seems to be a nice feature, however my
>> first concern would be the order of execution.
> If you need a specific order of execution, you should ensure that your
> depends attributes are correct.  If target "a" must be run before
> target "b" than "b" simply must depend upon "a".
> This is true with normal targets and I don't see why target-groups
> would change that.

My understanding is that the phase allow to incorporate targets that
doesn't know each other.  In that context imposing an order doesn't
make sense.

But I can imagine that when implementing 2 independent sets of targets
to be bound in a phase, you realize that they will only work properly
together when executed in a specific order.  For such a case, the user
will have no other choice than adding a phase.  Indeed, he probably
doesn't know if the 2 sets of targets will be always used together.
If such scenario is realistics then, we may also need to have a
"depends if executed" meaning that if target b must be executed, then
it must be before target a.
I think some experimentation will say if such ordering mechanism is required.

At the opposite, I could also imagine that the implementation make
sure that the targets are isolated.  I could imagine that the bounded
target are executed in isolation, and that all the properties and
reference that are defined are only visible when the phase is

I think both aproach are too extreme for the moment.  The guideline
(and the purpose) should be to have the possibility to bind
independant targets into a phase.

>> If I understand correctly the target-group, or phase (would be my
>> preference), is a very top-level element that simply specifies a grouping of
>> tasks, it doesn't deal with the order in which tasks are performed.
> It really only is a target, yes.  And it only exists for its depends
> list.  If the targets it depends on require a specific order, they
> better say so in their own depends lists.  If they can't, then this
> may hint at a missing phase.
>> So, this target-group element is only useful if order doesn't matter
>> in the phase, like in the example of having different types of
>> tests. If order does matter, this would then needed to be solved
>> using the depends attribute.
> Yes.
>> But that also requires making sure that certain targets are not
>> executed twice, which means one would need to add succeeded
>> properties and have unless conditions to check them, right?
> I don't think so.  targets will never run twice unless you do
> something like running "ant a b" on the command line where b depends
> on a.
>> In addition, perhaps dynamic inclusion of build files (within targets) can
>> be a valuable extension to this phase feature.
> Right now <import> and <include> must be used outside of targets and
> it would be pretty difficult to implement in any other way.
> The imported files define new targets.  If you import a file while
> executing a target you are modifiying the DAG of the running build
> targets.
>> Different question, but maybe related: is there a way to specify
>> that a build file should only be imported once (for instance, if
>> different nested files have import statements referring to the same
>> file)?
> This is the current behavior of <import>, any file will only be
> imported once and subsequent imports are ignored.
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Gilles Scokart

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

View raw message