ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: EasyAnt phases
Date Thu, 13 Nov 2008 03:06:35 GMT
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.

> 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.


> 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 <import> and <include> 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

> 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 <import>, any file will only be
imported once and subsequent imports are ignored.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message