ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Request for Failed-Task
Date Mon, 06 Nov 2000 07:47:38 GMT

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