ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Hennessy" <de...@network365.com>
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:

    <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="devteam@here.com" 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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message