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 12:00:41 GMT

Thanks for the explanation, it indeed seems to be a nice feature, however my
first concern would be the order of execution. I can imaging that the
easiest way to implement is a first-in-first-out approach (or
first-in-first-executed in this matter).

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. The
required order is still defined using the depends attribute on targets. The
order of registered targets will be defined by the attribute on the
target-group, plus the targets that register themselves once they are loaded
(load order is defined by normal processing of targets and imported build

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? Or spent time thinking about the order in
which targets or build files are imported into the project and processed.

Is there a way to solve the issue of ordered execution? I think that would
make it even more powerful.

In addition, perhaps dynamic inclusion of build files (within targets) can
be a valuable extension to this phase feature.
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)?



On Wed, Nov 12, 2008 at 8:21 AM, Jeffrey E Care <> wrote:

> "Remie Bolte" <> wrote on 11/11/2008 11:05:48 AM:
> > Can you explain the concept of targets being able to add themselfs as
> > dependencies?
> > I can't really picture this :)
> I wasn't involved in the definition of this so don't take my word as
> gospel, but this is my understanding:
> Assume you have a lot of projects & want to define a standard set of build
> files (with a standard set of targets) for them all to use. You have a
> "test" target for each project that can run any number of other targets to
> perform specialized testing tasks: load testing, unit testing, etc.
> As things are today your standard test target needs to know about every
> potential kind of testing that ANY of the projects MIGHT need to do & add
> each of those other targets as a dependency. You basically then have to
> define an empty implementation of each one of those specialized targets in
> your standard set of build files, otherwise your test target will blow up
> when building against one of your projects that doesn't implement some
> particular kind of testing.
> This target-group concept turns that around; think of it as dependency
> injection. It's defining a target name and saying "Hey, if you want to be
> run when I run, please tell me" as opposed to the current situation of "Hey,
> I know what I need to do without any help". It's a callback, an extension
> point, an event listener, pick a metaphor.
>   ____________________________________________________________________________________________
>  Jeffrey E. (Jeff) Care  ** <>
>  IBM WebSphere Application Server  WAS Release Engineering
>  [image: WebSphere Mosiac] [image: WebSphere Brandmark]

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