I'm very new to gradle and have a basic question.
When I add a custom task to my gradle.build file and call "gradlw build" or "gradle clean" or any other gradle command,
it automatically runs my custom task.
Is that how things work in gradle? run every task in the build file?
Is there way to run a task only when I want it manually?
task foo {
println 'hello'
}
That creates a task, and during the configuration of the task, it tells gradle to execute println 'hello'. Every task is configured at each build, because gradle needs to know what its configuration is to know if the task must be executed or not.
task foo << {
println 'hello'
}
That creates a task, and during the execution of the task, it tells gradle to execute println 'hello'. So the code will only be executed if you explicitly chose to run the task foo, or a task that depends on foo.
It's equivalent to
task foo {
doLast {
println 'hello'
}
}
You chose not to post your code, probably assuming that gradle was acting bizarrely, and that your code had nothing to do with the problem. So this is just a guess, but you probably used the first incorrect code rather than the second, correct one.
Related
I have the following:
task copyToLib(type: Copy) {
from configurations.runtime
into "$buildDir/output/lib"
doLast { copyOpcThirdParty() } // this doesnt get executed
}
task copyOpcThirdParty(type: Copy) {
from "$projectDir/libs/opc/thirdparty"
into "$buildDir/output/lib/thirdparty/"
}
How can I call copyOpcThirdParty from copyToLib.doLast?
I tried .execute(), tasks.copyOpcThirdParty, etc, nothing worked..
Is it unsupported?
In Gradle tasks are not executed directly. Instead you can register dependencies and Gradle then decides which tasks to execute in which order to achieve the execution of the tasks you specified (generally via command line). In older versions of Gradle you can call execute() directly on a task, but it should never be used.
When executing the tasks, the execution of one task must always be completely finished until another task can be executed. The execution of a task always covers running all doFirst closures, all internal task actions and all doLast closures.
For your specific example you can use the finalizedBy method. It tells Gradle that whenever a specific task runs, at some point after that another specific task also has to run:
copyToLib.finalizedBy copyOpcThirdParty
Does use of the gradle version in the wrapper task eliminate the need to use gradlew?
wrapper {
gradleVersion = '4.10.2'
}
task foo {
println "...bar"
}
The wrapper seems to be automatically executed as part of the "Configure project" phase and, if so, seems to be a "cleaner" way to manage this (i.e., less files to deal with, embedded in the actual gradle build script, etc.).
New to Gradle, just trying to figure things out...
Add...
I added the "foo" task to clarify my point of confusion.
1 - I am executing the script using "gradle foo"
2 - In the process, I note that the "wrapper" task is automatically invoked
My point-of-confusion is that it seemed that including the wrapper entry would force the right version of Gradle to be used (i.e., why else would the wrapper task be automatically invoked). On inspection, it appears that including the version in the wrapper task is another way to get the version into Gradle's properties file (vice providing it on the command line when generating the wrapper).
Live-and-learn, thanks for dealing with this question.
I am executing the script using "gradle foo" 2 - In the process, I note that the "wrapper" task is automatically invoked
No, it's not. If it was, then the following script would print "hello":
wrapper {
gradleVersion = '4.10.2'
doLast {
println 'hello'
}
}
task foo {
println "...bar"
}
What you see there is the configuration of the wrapper task, which would be invoked if you executed gradle wrapper, and would install (or upgrade) the wrapper for the version 4.10.2 of gradle in the project.
This task configuration is not needed anymore. As indicated in the documentation, you can invoke the wrapper task and specify the version directly on the command line with gradle wrapper --gradle-version 4.10.2.
Note that, in your script, the line println "...bar" is executed when the task foo is configured, not when it's executed. Whatever tak you execute, you will always see bar... printed in the console.
I have two task
task Hello {
println 'Hello'
}
task World {
println 'Hello1'
}
If I run World task Hellowill run also. If I modify my tasks in this way
task Hello {
doLast {
println 'Hello'
}
}
task World {
println 'Hello1'
}
then task Hellowon't run. How do doLast{} or doFirst{} sections affect running tasks in gradle?
I can't find information in gradle docs about that. Thx.
The task Hello doesn't run. It's configured.
The code inside the curly braces is the code that configures the task. This code is always executed, whatever the task you tell gradle to run. It must run so that gradle knows what the task does, on which other task it depends, which other task it finalizes, etc.
Once the configuration phase has finished, the execution phase starts. And in that phase, the task that you asked to execute is executed/ In that phase, the code passed to doLast is being executed.
Here's the documentation.
This is what i am trying inside the gradle task
task parse(type: Exec) {
standardOutput = new ByteArrayOutputStream()
executable 'make'
args "print_JDBC_CURRENT_JDK_OPT_JAR"
doLast {
project.ext.jdkver=standardOutput.toString()
}
}
println project.jdkver
Error: Could not get unknown property 'jdkver' for root project 'xyz'
of type org.gradle.api.Project.
Task actions, doFirst and doLast closures are executed during execution phase, but everything else in your build script, including your println statement is executed before that, during the so-called configuration phase.
Since the extension property is used before it's defined, the build fails.
If the value you determine is only required in another task, you can keep your approach and use the value in the tasks, if they are executed after this task (which you can ensure via dependsOn).
If you need the value in your configuration phase and independent from any task (or how you call Gradle), do not use an Exec task, but the exec method of your Project object, which will be executed immediately.
I've prepared a very simple script, that illustrates the problem I see using Gradle 1.7 (need to stick with it because of some plugins not yet supporting newer versions).
I'm trying to dynamically create tasks each of which corresponds to a file in the project directory. This works fine, but the tasks I create never get executed as soon as I assign them type 'Copy'.
Here is my problem build.gradle:
file('templates').listFiles().each { File f ->
// THIS LINE DOES NOT WORK
task "myDist-${f.name}" (type: Copy) {
// NEXT LINE WORKS
//task "myDist-${f.name}" {
doLast {
println "MYDIST-" + f.name
}
}
}
task distAll(dependsOn: tasks.matching { Task task -> task.name.startsWith("myDist")}) {
println "MYDISTALL"
}
defaultTasks 'distAll'
in this way my tasks do not get executed when I call default task calling simply gradle:
MYDISTALL
:myDist-template1 UP-TO-DATE
:myDist-template2 UP-TO-DATE
:distAll UP-TO-DATE
BUILD SUCCESSFUL
If I remove type Copy from my dynamic task (uncommenting the line above), my tasks get executed:
MYDISTALL
:myDist-template1
MYDIST-template1
:myDist-template2
MYDIST-template2
:distAll
BUILD SUCCESSFUL
(You'll need to create a folder name templates in the same directory where build.gradle is located and put couple of empty files into there in order to run the test)
According to the debug output:
Skipping task ':myDist-template1' as it has no source files.
Skipping task ':myDist-template2' as it has no source files.
So how can I specify source files and make my Copy tasks execute?
I've tried adding
from( '/absolute/path/to/existing/file' ) {
into 'myfolder'
}
to the task body, I've tried assigning task's inputs.source file('/my/existing/file') with no success.
Could you please advise on how to modify my simple script leaving dynamic task creation and keeping my dynamic tasks of type Copy?
Thank you!
Edit:
All right, this way the task gets called:
file('templates').listFiles().each { File f ->
task "myDist-${f.name}" (type: Copy) {
from f
into 'dist'
doLast {
println "MYDIST-" + f.name
}
}
}
but it looks I must always specify from/into. It doesn't suffice to do that in the doLast{} body.
A Copy task only gets executed if it has something to copy. Telling it what to copy is part of configuring the task, and therefore needs to be done in the configuration phase, rather than the execution phase. These are very important concepts to understand, and you can read up on them in the Gradle User Guide or on the Gradle Forums.
doFirst and doLast blocks get executed in the execution phase, as part of executing the task. Both are too late to tell the task what to copy: doFirst gets executed immediately before the main task action (which in this case is the copying), but (shortly) after the skipped and up-to-date checks (which are based on the task's configuration). doLast gets executed after the main task action, and is therefore clearly too late.
I think the following Gradle User Guide quote answers my question the best:
Secondly, the copy() method can not honor task dependencies when a task is used as a copy source (i.e. as an argument to from()) because it's a method and not a task. As such, if you are using the copy() method as part of a task action, you must explicitly declare all inputs and outputs in order to get the correct behavior.
Having read most of the answers to "UP-TO-DATE" Copy tasks in gradle, it appears that the missing part is 'include' keyword:
task copy3rdPartyLibs(type: Copy) {
from 'src/main/jni/libs/'
into 'src/main/libs/armeabi/'
include '**/*.so'
}
Putting from and into as part of the doLast section does not work. An example of a working task definitions is:
task copyMyFile(type: Copy) {
def dockerFile = 'src/main/docker/Dockerfile'
def copyTo = 'build/docker'
from dockerFile
into copyTo
doLast {
println "Copied Docker file [$dockerFile] to [$copyTo]"
}
}
Not the behavior I was expecting.
Using gradle 3.2.1