Force task to always run continously

plugins

(John Ahlroos) #1

Hi,

I’m trying to get a task I have to always run continuously without the user needing to always add -t when running the task.

I thought

project.gradle.startParameter.setContinuous(true) 

would do the trick but apparently this is read too early. Changing the task names this way seems to work though which left me confused.

Any suggestions?


(Sterling Greene) #2

Do you have an example of what a “continuous task” would be?

I don’t believe this is possible because continuous build is a property of the overall build, and we need to start the build in a way that allows it to re-execute. Setting the start parameter in the configuration script would be too late for that.


(John Ahlroos) #3

The task I’m thinking about is part of a plugin that is starting an embedded jetty server to run a web app and re-deploying if any classes have changed. Basically the same idea as the Gretty plugin.

Currently we have our own custom logic for doing this which basically hangs the task and uses the java.nio WatchService to monitor changed classes. It works but is most likely the same as Gradle has built in with the continuous build feature so I was looking if I could re-use that and get rid of some custom code.

Since we already can add and re-order tasks using gradle.startParameter.taskNames, I don’t see it much different to be able to also set other options in StartParameter at the same time as well.


(Sterling Greene) #4

The StartParameter isn’t really meant to be used that way for the currently executing build. It just happens that we don’t currently inspect the list of tasks until after we’ve evaluated the build script. The continuous build flag is something we have to know earlier. This is similar to other things that are available from StartParameter, like buildFile.

What kinds of things do you need to change when you modify taskNames?


(John Ahlroos) #5

We’re using taskNames in a plugin to add a task that always executes first and only once, even in a multimodule build where the plugin has been applied to multiple modules. We couldn’t find a better way of doing that other than prepending the task name as first in the taskNames list.