ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Hennessy" <>
Subject RE: To fail or not to fail
Date Fri, 30 Nov 2001 16:36:05 GMT
I like the idea of giving the user more control over what constitutes a
build abort. Currently, it seems the model is that each target is made
'complete' by a series of sequential tasks, each of which must run
successfully or everything fails. Some tasks like <junit> have explicit
attributes that bypass this behaviour (so they return success for a task
that, in fact, failed).

It would be also nice if any task could be treated as a condition,
enabling a task like <condition> to run them and then set a property
based on the result. This opens the way to a fully general-purpose
scripting representation of the required behaviour.

Having said all that, I would hate to have to add an <if>....<fail>
around every required task:


So I think perhaps the existing behaviour is in fact OK, and we should
look for a way to extend it without breaking the simplicity of
expression it contains. How about a new task container that provides the
ability to change what happens on an error:

    <try capture="msgs">
            <echo message="Unit tests failed, notifying dev team"/>
            <mail to="" subject="Build Failed"

Perhaps a series of task containers <if> <unless> <while> <try> each
which run tasks in a no-abort environment.


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

View raw message