Adam Murdoch wrote:
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.
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.
Thoughts?
Any solution to this problem absolutely must be non-invasive to be worth
the cost. If not, you're effectively making everyone who writes Gradle
code (build scripts included) pay a price to make their code
cancellable, whether or not they or anybody else ever want to cancel it.
What's the problem with using ctrl-c or System.exit() or
Process.destroy() ?
That is, if you want to be able to cancel a build, you need to run it in
forked mode.
The point of this was to provide a cancel mechanism when using Gradle embedded
inside another application (in this case for the IDEA plugin). We originally
were not forking the execution of Gradle because we thought we would be able to
run the configuration phase once and re-use some Gradle object to execute the
tasks. This turned out to not be possible, so we could look into forking again.
I do think we are getting significant startup time savings from running this
without forking, but we could test this to be sure.
I don't think that everyone writing a DefaultTask in a build script would need
to be concerned with this. There are a few more typically long running built in
tasks (like test) that might need to know about this, but for the most part we
would be happy with just stoping the TaskExecutor from picking up the next task
in the chain.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
