ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <>
Subject RE: Request for Failed-Task
Date Wed, 08 Nov 2000 20:14:18 GMT
I guess by applying the "most-simple"-rule to this, the following proposal
should be the most simple and with least unexpected side-effects:

<project name="foobar" default="build">
	<target name="build">
		<!-- get it done and fail -->
		<echo msg="The build was a complete failure!">

These are not nested, chained or whatever. If a project calls another
project the ant-call will fail so the failure-task of the callees project
needs to be run as well. The only thing that I'm not completely certain
about is if ant-calls are within the same project. The failure-task skould
only run once but it doesn't come naturally...

I think the alternative for having a specific failure-target is to have a
listener-task so that you can add listeners at run-time. That's probably the
easiest way to do all this, but it's not as explicit as a failure-task.

-----Original Message-----
From: Steve Loughran []
Sent: Sunday, November 05, 2000 11:48 PM
Subject: Re: Request for Failed-Task

----- Original Message -----
From: "Conor MacNeill" <>
To: <>
Sent: Sunday, November 05, 2000 7:31 PM
Subject: RE: Request for Failed-Task

> If failure targets cannot have dependencies then they are not really
> targets - they are something else. If they can't have failure attributes
> then, again, these failure targets are not targets. If you are going to
> introduce such restrictions then you want something which is not really a
> target anymore, it is something more like a <failure> element which could
> contain tasks but not have depends or failure attributes.
> Conversely, without such restrictions, the complexity goes up, as does the
> scope for things like infinite failure loops.
> Thoughts?

If this has to be done, then I prefer the notion of a special clause, not a
'target'. They need to be given a special name like, say, 'exception'

That is after all, what is effectively being proposed.

Now: should the exceptions chain? That is, is the exception handler in
"main" called if it is the subtask "build" that failed? Next :does the
successful handling of an exception of a single target mean that the next
item in the build process could continue? We are teetering above a very
slippery slope of extra complexity here.

The only exception/failed task that would avoid most of these problems would
be a handler with project scope. Maybe somehow some properties could be
dynamically defined with failing task name, target and line. But all the
handler could do is some more tasks (no depends) and a failure is defined as

Even then, I dont know if it is needed. Something that simple could be
implemented by using a special ant invocation script that called a build.xml
file with a different target "build-failed"


View raw message