Request for Failed-Task

[Thomas Christen <ch...@active.ch>]

As far as I know, there is currently only a solution to handle a "Fail"
through a Listener. This means one has to write a Listener first. It would
be nice to have default behaviour in case a build fails like a target failed
witch will be called in this case.

Thomas Christen

RE: Request for Failed-Task

[Jon Tirsén <jo...@emm.com>]

Sorry, bit of a typo went in to this one:
> There are some issues to consider on this one though: If a target fails
> should just the targets failure-target be run or should the targets that
> depended on this one also be run?

Should of course be:
There are some issues to consider on this one though: If a target fails
should just the targets failure-target be run or should the targets that
depended on this one's failure-targets also be run?

RE: Request for Failed-Task

[Jon Tirsén <jo...@emm.com>]

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 -->
	</target>
	<failure>
		<echo msg="The build was a complete failure!">
	</failure>
</project>

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 [mailto:steve_l@iseran.com]
Sent: Sunday, November 05, 2000 11:48 PM
To: ant-dev@jakarta.apache.org
Subject: Re: Request for Failed-Task



----- Original Message -----
From: "Conor MacNeill" <co...@ebinteractive.com.au>
To: <an...@jakarta.apache.org>
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
final.

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"

-Steve

Re: Request for Failed-Task

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Conor MacNeill" <co...@ebinteractive.com.au>
To: <an...@jakarta.apache.org>
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
final.

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"

-Steve

RE: Request for Failed-Task

[Conor MacNeill <co...@ebinteractive.com.au>]

Jon,


> -----Original Message-----
> From: Jon Tirsén [mailto:jon.tirsen@emm.com]
>
[snip]
>
> Of course, there are some issues here as well: If a project is called from
> another project whould all the failure-targets be run in the chain? If a
> task is called from within the same project should the
> failure-target be run
> several times? Probably not, but what are the semantics? I
> imagine it would
> be healthy to reuse the same semantics as with ordinary targets,
> if it's run
> it does not need to be run again...
>
> Also (for both A and B) could failure-targets have "dependants"
> and what if
> they fail?
>
> And, of course, applying the "keep-things-simple" general rule (occhams
> razor), is there a way to design this simple enough? ASAP (= As Simple As
> Possible ;).
>

Is that Pandora's box I hear creaking open :-)?

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?

Conor

RE: Request for Failed-Task

[Jon Tirsén <jo...@emm.com>]

Yes, that could be a useful feature. For my current build-system I would use
it for posting a Change Request into StarTeam if the nightly build fails.
Currently I implement this by having a script calling ant that checks the
exit-code and calls another target if ant fails. It would be nice to be able
to specify all semantics of a build in ant instead.

I imagine their could be two different ways of implementing this
A) Set a failure target on target-level:
<project name="foo">
	<target name="nightlybuild" failure="failure">
		<!-- do your deed -->
	</target>
	<target name="failure">
		<!-- create change request -->
	</target>
</project>

There are some issues to consider on this one though: If a target fails
should just the targets failure-target be run or should the targets that
depended on this one also be run?

A little bit easier, but not as powerful:
B) Set a failure-target on project-level, with basically the same semantics
of the default target:
<project name="foo" failure="failure">
	<target name="nightlybuild">
		<!-- do your deed -->
	</target>
	<target name="failure">
		<!-- create change request -->
	</target>
</project>

Of course, there are some issues here as well: If a project is called from
another project whould all the failure-targets be run in the chain? If a
task is called from within the same project should the failure-target be run
several times? Probably not, but what are the semantics? I imagine it would
be healthy to reuse the same semantics as with ordinary targets, if it's run
it does not need to be run again...

Also (for both A and B) could failure-targets have "dependants" and what if
they fail?

And, of course, applying the "keep-things-simple" general rule (occhams
razor), is there a way to design this simple enough? ASAP (= As Simple As
Possible ;).


-----Original Message-----
From: Thomas Christen [mailto:chr@active.ch]
Sent: Sunday, November 05, 2000 6:18 AM
To: Ant-Dev
Subject: Request for Failed-Task


As far as I know, there is currently only a solution to handle a "Fail"
through a Listener. This means one has to write a Listener first. It would
be nice to have default behaviour in case a build fails like a target failed
witch will be called in this case.

Thomas Christen