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:
<if>
<javac>....</javac>
<fail>
</if>
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">
<junit>...</junit>
<onerror>
<echo message="Unit tests failed, notifying dev team"/>
<mail to="[EMAIL PROTECTED]" subject="Build Failed"
body="${msgs}"/>
<fail/>
</onerror>
</try>
Perhaps a series of task containers <if> <unless> <while> <try> each of
which run tasks in a no-abort environment.
Regards,
Denis
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
