ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remie Bolte" <>
Subject Re: EasyAnt phases
Date Wed, 12 Nov 2008 16:42:05 GMT
> By declaring your target to be part of a given group, you are indeed
> adding yourself as an *unordered* dependency on that phase (which is
> just like a body-less target), but as you target you still have
> dependencies, on other targets *or* target groups which will be what
> dictates the ordering. If you specify your dependencies correctly, the
> order will be correct. That's always been the case, and target groups
> don't change that.

There is one change: the current Ant behavior is to respect the order in
which dependencies are set. The phase as currently proposed does not deal
with this, making it only usable in certain use cases.

As a separate note, it's bad practice IMHO to rely on dependencies to
> execute in the order a target specifies them. You should think in
> terms of requirements for the target to complete successfully, and not
> worry about the order. There's even a custom target executor that
> removes the default Ant behavior to honor the order of the direct
> dependencies and simply relies on the DAG topological sort, which is
> the way to go in fact. --DD

Dependencies in any way always have a specific order: you have a list of
requirements, and sometimes they themselves also have a list of
requirements, creating a nested dependency relationship. In complex designs,
this will automatically result in a DAG scheme for the nested dependencies
will probably have overlap. We are currently implementing the same view in
our product builds. For optimization reasons, we use conditions to prevent
duplicate execution of targets.

Having said that, there are use-cases in which having an ordered execution
of depending products makes sense, where implementing a DAG scheme would
make our world more complex than truly required. It is probably also this
pragmatic approach that caused the default target executor in Ant to still
respect the dependency order. That same pragmatic argument could be used in
this discussion: it would be a nice-to-have if it would be possible to
influence the order in which targets are executed in the phase.

However, I do see that this feature request creates an implementation
nightmare :)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message