> 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 :) Cheers, Remie
