Two questions:
taskName.execute()
method does not honor the dependsOn relationships of taskName
is this true and what is the work-around?More background:
Right now I have a build script that has no plugins (not Java in other words). I want a task called tests
that will run all my test tasks. I have 3 such tasks. Call them task1, task2, and task3.
I could say tests.dependsOn ['task1', 'task2', 'task3']
This is a bit wonky because the relationship seems to be tests.isComprisedOf ['task1', 'task2', 'task3']
I could say:
task tests << { task1.execute() task2.execute() task3.execute() }
but then task3, which itself depends on taskSetup, runs without running taskSetup. In other words the execute() call does not seem to honor gradle's dependencies resolution strategy.
One last small gripe (I really do love gradle by the way), is that it is hard to search on this topic because dependency means two different things in gradle: dependsOn style dependencies and library style dependencies.
dependsOn(jar) means that if you run assemble , then the jar task must be executed before. the task transitive dependencies, in which case we're not talking about tasks, but "publications". For example, when you need to compile project A , you need on classpath project B , which implies running some tasks of B .
The dependency tree in a build scan renders the selection reason (conflict resolution) as well as the origin of a dependency if you click on a dependency and select the "Required By" tab. Every Gradle project provides the task dependencyInsight to render the so-called dependency insight report from the command line.
The work that Gradle can do on a project is defined by one or more tasks. A task represents some atomic piece of work which a build performs. This might be compiling some classes, creating a JAR, generating Javadoc, or publishing some archives to a repository.
Dependency ordering is preserved, but for example all compile dependencies will be before testCompile dependencies no matter of how you order them. Depending on the nature of your conflict you could also exclude the dependency from 'testCompile' rather than force the correct one higher on the classpath.
Typically, you do not invoke task.execute()
.
You can specify that one task is comprised of other tasks in the following manner:
task task1 << { println "Hello" } task task2 << { println "World" } task task3(dependsOn: 'task3dependency') << { println "QBert" } task task3dependency << { println "MR" } task tests(dependsOn: ['task1', 'task2', 'task3'])
This outputs:
$ gradle tests :task1 Hello :task2 World :task3dependency MR :task3 QBert :tests BUILD SUCCESSFUL
Keep in mind that the order in which your dependency tasks are run is not always guaranteed, but you can mitigate this by specifying the order task2.mustRunAfter task1
. Usually though, the tasks are run in the order you would expect.
Also, you should read up on Gradle's Build Lifecycle. When you use the syntax task task1 << {...}
, you are specifying a closure that is run in the execution phase of the task. Before execution is run, the configuration phase evaluates your build script and determines the tasks to be run and in what order. When you manually execute tasks, as in:
task tests << { task1.execute() task2.execute() task3.execute() }
you have bypassed Gradle's ability to evaluate the task dependencies of task3, hence it runs only task3.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With