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
finished.
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 and 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 , any file will only be
> imported once and subsequent imports are ignored.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org