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 20:51:57 GMT
I agree that it doesn't make it right, however, it makes it a point to

One might even argue that the two do not exclude each other: in the current
implementation an order depending design pattern and a DAG implementation
can co-exist. Personally I would not vote for enforcing either design
pattern for I think both have merit.

Hence I also believe that it would serve the community to enable the
possibility of ordered execution in the target-group / phase element. Maybe
not as default behavior, but as additional feature. It doesn't make it
right, but it probably will makes someones life a bit easier :)


On Wed, Nov 12, 2008 at 6:37 PM, Jeffrey E Care <> wrote:

> "Remie Bolte" <> wrote on 11/12/2008 11:42:05 AM:
> > > 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.
> Someone correct me if I'm wrong here, but AFAIK there's nothing in the
> documentation that states target dependencies will be executed in the
> order listed. The fact that the default executor respects the order is a
> side effect of the implementation, not a guaranteed behavior.
> The fact that many projects do in fact rely on target dependencies being
> executed in listed order doesn't make it right.

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