ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Problems with <import>
Date Sat, 20 Jul 2002 16:17:17 GMT

An alternative:
    <onStart target="init" />
    <onEnd   target="destroy" />


The 'onStart' task can look up the project and insert 'init' as a 
dependecy to all other targets. 'onEnd' can use the end event
and call destroy ( well, that's a bit tricky - it'll probably need
some changes in core )

I like the idea of 'meta-tasks' - like <import>, <taskdef>, etc - that
operate on the project. Many of them will be possible for 1.5 using
the project helper hook, but in some cases like destroy we'll need
core changes and 1.6.


On Sat, 20 Jul 2002, Dominique Devienne wrote:

> 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"
>          default="build"
>          first="init"
>          last="finally">
>   <!-- All targets implicitly depend on this target,
>        thus saving adding depends="init, ..." to them -->
>   <target name="init">
>     <tstamp/>
>     ...
>   </target>
>   <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 ... />
>   </target>
> </project>
> 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 ;-)
> --DD
> -----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 
> lines.
> >which
> > 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.

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

View raw message