On Jul 24, 2009, at 12:41 AM, Steve Appling wrote:
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.
The relevant startup time cost here is the Groovy startup time. It
would be nice to get around this.
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.
Look for example at the ftp task of the Gradle build which uploads the
Javadoc. It takes many minutes to finish. It simply uses the Ant FTP
task, so it would ignore any StopEvent until it is finished. But a UI
runner should be able to stop such a task more or less immediately.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
