I think I have some ideas for a way to avoid the startup costs but still fork
the build. I will investigate this in our current GUI runner.
Please consider our request for a cancellation mechanism on hold. Thanks for
taking the time to discuss this enough to prompt me towards a better solution.
Hans Dockter wrote:
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
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
