ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remie Bolte" <re...@backbase.com>
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
consider.

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 :)

-r


On Wed, Nov 12, 2008 at 6:37 PM, Jeffrey E Care <carej@us.ibm.com> wrote:

> "Remie Bolte" <remie@backbase.com> 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.

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