Hans Dockter wrote:
Hi,
I'm thinking about the best way to implement stopping a Gradle build.
One way to do it would be to add a type BuildController. A instance of
this can be optionally passed to the Gradle.run method. The TaskExecuter
and the Task will be associated with an instance of BuildController. If
the state of the build controller is changed to stop, the TaskExecuter,
Task, etc can react upon this and will throw eventually a
BuildInterruptedException. This is a pretty intrusive approach. It has
the additional draw back, that every task needs to be smart about this
to make it work well. For example a task that delegates to an Ant task
must wait with stopping the build until the Ant task has finished.
I think that every task that can take advantage of this does need to be smart
about it. They may have differing requirements for how to cleanly stop. Tasks
that can't stop (like ones that now delegate to ant) don't have to do anything.
They will execute as normal and allow the TaskExecutor to stop further execution.
I think that tasks shouldn't have to poll the state of the BuildController, but
should be able to register as a listener for a cancellation request. It would
seem clean to me to just add a BuildListener.cancelRequested method. Tasks that
can cancel can register as a listener. Or perhaps you could add another
listener interface for this purpse.
Another way of doing this is to still add a type BuildController. You
can send a StopEvent to the BuildController. We have a separate Thread
that receives this StopEvent. If it is received, the Thread running the
Gradle build will be stopped.
I'm worried that just killing the Gradle thread will be unsafe. When there are
multiple child threads (like is currently done for change detection or will be
done for new test execution), I'm not sure that they will all be stopped
appropriately. I would also worry about possibly corrupting some type of state
files (like change detection uses) if it was terminated at the wrong time.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
