How to avoid using xxxx.execute() to specify task order?

We have build tasks which run integration tests on the code, which start a Tomcat server in daemon mode, run some tests, then shut it down.

An example of this would be:

task bddTest(…) {

doFirst {

System.setProperty(“”, “InMemoryAuth,MockDB”)

tomcatRun.daemon = true



doLast {




bddTest runs Cucumber via javaexec.

I’ve been told by a Gradle guru that calling .execute() on tasks directly is bad. However, getting things right without it is quite difficult - as you can’t just create several tasks and have the task which should execute them specify them via a ‘dependsOn([startTomcat, runTests, stopTomcat)’ call, as dependsOn order isn’t honored.

Here’s my next attempt:

task daemonModeBddTomcat(type: org.gradle.api.plugins.tomcat.TomcatRun, dependsOn: [compileBddTestJava, processBddTestResources, bddTestClasses]){

daemon = true


task bddTestCore(dependsOn: [daemonModeBddTomcat])

task bddTest(type: org.gradle.api.plugins.tomcat.TomcatStop, dependsOn: bddTestCore)

The task bddTestCore (in the second example) runs Cucumber as bddTest did in the first.

What folks are complaining about is that the task they think they’re running actually shuts down Tomcat, but it depends on the Cucumber task running before that, and Tomcat starting before that. Secondly, they think that three tasks being required to do the job vs. one task in the previous method is unwieldy.

What’s the “proper” Gradle way to do this? I know that creating the proper tasks can let the DAG do it’s thing better, but they wanted me to get “official” confirmation about that (or else start a flame war).

Thanks in advance

Douglas Bullard Nike, Inc.

Hi Doug,

Right now, your only real option is to do things the “wrong” way.

The core problem here is that the tomcat (and jetty, which it was inspired from) plugin only presents a task interface to its functionality. If it offered a POJO based interface then you wouldn’t have to manually execute a task.

The problem with manually executing a task is that it’s not supported and could easily break in new Gradle versions. There are also some potential weirdness that can occur if something else tries to use it (whether that’s task execution proper or another task). For now, I’d personally stick with the manual execution and work to get the tomcat plugin “fixed”.

I’ve raised a contribute idea on this and will ping the tomcat plugin author to get his thoughts on it.