2009/7/23 Steve Appling <[email protected]> > > > 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.
I like this idea, some tasks might want/need to be able to be canceled (like test). > > > >> 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. It is possible to cancel change detection but only at certain points and the change detection logic needs to be able to handle the cancel otherwise it'll be in a bad state, while it is hashing you can cancel it and just remove the new state files, during hash comparison it really depends on what the actions following state changes are and that will really depend on where the change detection is used that will determine whether it may be canceled at this stage. Test execution is indeed going to have multiple threads involved in executing tests and we need to foresee that the execution can be stopped before the tests complete so that is only going to be possible by making this information available, so a listener that informs the test execution sound like a good idea. > > > -- > Steve Appling > Automated Logic Research Team > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
