Putting it as a global setting makes sense, as you would need coordination between tasks to honor the failAtEnd consistently.
As to making it the default behavior, it should at least be configurable. There are definitely different builds (especially potentially long ones) that you want to fail fast when there is any problem, and others that you want to build as much as possible before finally failing. I prefer a fail fast default as it is now, but think a configurable failAtEnd has a lot of value. -Spencer --- On Sun, 1/23/11, Adam Murdoch <[email protected]> wrote: From: Adam Murdoch <[email protected]> Subject: Re: [gradle-dev] Task Error Handling To: [email protected] Date: Sunday, January 23, 2011, 7:53 PM On 23/01/2011, at 9:10 PM, Hans Dockter wrote: A task might produce information that is sufficient to let the build fail (e.g. a failing test). But the output of the task is still complete (in contrast to a failing compile) so the build could continue with gathering more information (e.g. failing tests in other subprojects). But the build should fail at the end. What about giving every task a property like: failAtEnd At the end (or in the case of an immediate fail) we would list all delayed error messages. Thoughts? I think this would be very useful. I wonder, though, if this is a function of the type of build being performed, rather than of a task, ie perhaps this should be a global setting on the Gradle instance. Or, perhaps, Gradle should always work this way. That is, Gradle always attempts to perform as much of the requested work as possible, even in the presence of failures.
