ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: Problems with <import>
Date Sat, 20 Jul 2002 15:09:09 GMT
Why can we just add two attributes to <project>, similar to 'default', which
specifies the 'first', and 'last' target of the build? Both these attributes
would be optional. I think it makes things pretty expressive:

<project name="antx"

  <!-- All targets implicitly depend on this target,
       thus saving adding depends="init, ..." to them -->
  <target name="init">

  <target name="build"
          depends="compile, test, jar" />


  <!-- This target will always be run before this ant run terminates,
       whether successfully or not -->
  <target name="finally">
    <mail ... />


Now the question would be whether targets defined as being the 'first' and
'last' targets should be allowed to have dependencies on other target
themselves (a 'depends' attribute basically). The reason I'm asking is what
should be the bahovior if the 'first' target depends on target A, so A is
executed before 'first', and later a regular target also depends on A...
Should A be executed a second time, or is it considered already fired. I'd
say that the latter is more natural, since it's like having the 'first'
target automagically added in front of the 'depends' attribute of all
targets (except the 'first' and 'last' targets of course).

But the behavior is less obvious for 'last'! Having a 'last' target is not
equivalent to append the 'last' target to all targets 'depends' attribute.
It has to run *after* the target, not *just before* the target. It's more
equivalent to an <antcall target="'last'"/>. I'm thinking maybe the 'last'
target shouldn't be allowed a 'depends' attribute.

Should regular targets be allowed to depends on the 'first' (seems harmless)
and 'last' targets? If the 'last' target has already been executed as part
of the dependencies of a regular target, should it be re-executed after the
last target?

And when is the last target executed? When one specifies more than one
target on the ant command line, it's almost equivalent as a different Ant
invocation for each target. So when you run one Ant command, you would
execute the 'first' and 'last' targets as many times as you have targets
listed on a single Ant command line!!!

The more I think about this, the more it seems to open more cans of worms...
The 'first' target stuff can already be achieved with a little typing, and
the 'last' target stuff can be achieved using loggers (right?). I'd rather
have Ant be able to specify the loggers/listeners/options it takes now on
the command line inside the Ant build script itself. One could define a
"finally" logger directly in Ant, to mail build results for example. So far
I don't remembering people wanting a 'last' target for anything else than
that anyway. If one wants to implement something else, then one uses another
pre-canned logger, or rolls up onces own.

Hopefully some of the above makes some sense ;-)

-----Original Message-----
From: Nicola Ken Barozzi []
Sent: Saturday, July 20, 2002 4:52 AM
To: Ant Developers List
Subject: Re: Problems with <import>

J.Pietschmann wrote:
> Nicola Ken Barozzi wrote:
>> The fact is that we need to be able to run *any* task at init.
>> There are two options:
>> 1) make all tasks runnable top-level
>> 2) deprecate using top-level tasks and add an <init> tag
> Why does everything have to be a task? I'd rather think
> property and filesets to be as definitions with some
> sort of scope.

Conceptually I agree.

> IMO an init task is redundant, because you can always have
> an init target.

And put depends="init" to every single target?
I want to tell the build system that *all* targets need to have init run 
before, in an AOP manner.

Doing it by hand has the same result, but not the same meaning, and I 
can overlook doing it too.

It also has relevance when importing, if the imported buildfile wants to 
enforce some things to be run always: for proper hiding, I shouldn't 
have to write depends="super.init".

> A destroy task is another matter, though
> I'd rather think of defining "error handling targets" 

Good suggestion. Error handling should be done somewhere between these 

> may include the possibility to define a target which is
> always called on exit.

Here it's the same as with <init>, I want the possibility of having 
*all* targets have that one called after, instead of writing every each 
single time which is a major PITA.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

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

View raw message