I need to transfer file names from Android application variants to Maven publication artifacts. The construct in my build.gradle is:
publishing {
publications {
maven(MavenPublication) {
groupId android.defaultConfig.applicationId
artifactId 'apk'
version = project.ext.version
artifacts = {
def list = []
android.applicationVariants.all { variant ->
variant.outputs.each { output ->
list.add (output.outputFile.absolutePath)
println "Output " + output.outputFile.absolutePath + " list " + list
}
}
println "To deploy " + list
list.iterator()
}
}
}
}
No artifacts are ever deployed with this script, and it produces the output that looks like a raise of machines:
To deploy []
Output B:\ox\app\build\outputs\apk\app-debug-1.0.apk list [B:\ox\app\build\outputs\apk\app-debug-1.0.apk]
Output B:\ox\app\build\outputs\apk\app-release-1.0.apk list [B:\ox\app\build\outputs\apk\app-debug-1.0.apk, B:\ox\app\build\outputs\apk\app-release-1.0.apk]
So all files were nicely iterated through, but for some reason the last print statement runs before the terminal print statement, and all construct just returns the empty list.
Why does this happen, and how to fix this? I need to set the list of iterated files and the artifacts property for Maven publication.
Gradle is a declarative language, so order of statements is not important. The builds are executed in following way:
1) script is evaluated in order it's written. That's how Gradle find out about what tasks you have in your script and which plugins to load. Not that tasks themselves are not executed at that point.
2) Then Gradle constructs a DAG of all the tasks that need to be executed. Each task can declare dependencies which are the tasks that must be executed beforehand.
3) After DAG is constructed, the tasks are run. The tasks are run according to their declared dependencies. Tasks with no dependencies are run first, possibly in parallel. The tasks that had dependencies are scheduled to run after all their predecessors have finished. Again if possible Gradle will run things in parallel.
3a) Tasks themseleves are run in following order. First doFirst {} blocks are executed, then the task body and after that the doLast {} blocks.
So in your case if you want to compose the list of artifacts, you should enclose your iterator into doFirst {} block.
Related
I have a gradle task for copying, like below:
task hello << {
println "hello"
}
task myCopy(type: Copy) {
println "copy"
from(file('srcDir'))
into(buildDir)
}
but "myCopy" task gets executed even when I execute "hello" like below:
gradle hello
Now I understand this is the intended behavior. I read thru the entire Gradle Task page here: https://docs.gradle.org/current/userguide/more_about_tasks.html . But I want to make "myCopy" task only execute when explicitly executed. In other words, I want to make it so that "myCopy" does not execute when I execute "hello", and only execute when I run the command:
gradle myCopy
Is there a way to do this? Thanks
It's not getting executed, but getting configured. Take a closer look, nothing get copied if you don't run your copy task. Configuration is happenning always and for all the tasks you have, in your case you are printing "copy" during the configuration. Move it into the doLast section to print it at the execution phase, as:
task myCopy(type: Copy) {
doLast {
println 'Copy'
}
from(file('srcDir'))
into(buildDir)
}
Note, that doLast closure is the same as a task closure with << sign and it is executed only if task executed at the execution phase.
It was my understanding that printlns get displayed during a task's configuration phase (unless they are for example placed within a doLast action). Therefore given the following task:
ext {
changeset = 'placeholderChangeset'
}
task getChangeset {
process = '/usr/bin/git describe --always'.execute()
process.waitFor()
changeset = process.getText()
println "Changeset obtained from GIT is: $changeset"
doLast {
println '\n++++++++++++++++++++++++++++++++++'
println '+++++ task getChangeset executed'
println '++++++++++++++++++++++++++++++++++++'
}
}
If I run this using ./gradlew then the output will be:
********************************
** task getChangeset
********************************
Changeset obtained from GIT is: 9bd49ca
If it run it using ./gradlew getChangeset then the output will be:
********************************
** task getChangeset
********************************
Changeset obtained from GIT is: 9bd49ca
...
:app:getChangeset
++++++++++++++++++++++++++++++++++
+++++ task getChangeset executed
++++++++++++++++++++++++++++++++++++
In the first run, the task has not been executed. Yet the value of the changeset is displayed, and therefore the process = ... execute() line has been executed.
Therefore I'm confused, what does it actually mean for a task to be "executed", if in this example, it obviously doesn't mean the code statements within the task haven't executed, as they most clearly have in order to get the value of the changeset.
What's the difference between a task not executing and a task executing if its not having an effect on the execution or non execution of the code within the task?
A println isn't somehow special or different from other code. Any code that is not inside the doLast{} block will be executed in the configuration phase, and the dolast{} block will be executed in the execution phase.
What is the difference between the code below?
task A {
println 'configuration'
}
task B << {
println 'action'
}
I believe it has something to do with evaluation.
ie task A is always evaluated
whereas task B is only evaluated when its executed
Indeed: the 'println' statement of your task A will be executed during 'configuration' phase, whereas the 'println' statement of taks B will only be executed during 'execution' phase (assuming task B is run, directly or indirectly via task dependencies)
For more info, checkout: http://www.gradle.org/docs/current/userguide/build_lifecycle.html. Section 56.2 has a nice example (also demonstrating the third phase, being the 'initialization' phase, BTW)
Note: the "<<" is a shorthand notation for "doLast"
In my build.gradle script, I have a lot of tasks, each depending on zero or more other tasks.
There are three 'main' tasks which can be called: moduleInstallation, backupFiles and restoreFiles.
Here's the question: I would like to be able to tell Gradle which tasks to execute and which don't need to execute. For example, when calling moduleInstallation, I want all depending tasks to execute (regardless of their UP-TO-DATE flag), but not the restore tasks. I've tried altering the phase in which the tasks get executed (e.g. config phase, execution phase,...) and a couple of other things, but all tasks just keep getting executed.
A solution I've thought of was just stating in the main tasks that, when this main task is called (f.e. moduleInstallation), we set the UP-TO-DATE flag of all non-related tasks to false, so they don't get executed. Is that possible?
EDIT: Here's an example:
When moduleInstallation is called (which depends on backupFiles), restoreFiles (which depends on restoreFromDate) is executed too.
First main action
task moduleInstallation << {
println "Hello from moduleInstallation"
}
task backupFiles {
doLast {
println "Hello from backupFiles"
}
}
Second main action
task restoreFiles {
println "Hello from restoreFiles"
}
task restoreFromDate {
println "Hello from restoreFromDate"
}
Dependencies:
moduleInstallation.dependsOn backupFiles
restoreFiles.dependsOn restoreFromDate
So when I type gradle moduleInstallation in the terminal, I get the following output:
Hello from restoreFromDate
Hello from restoreFiles
Hello from backupFiles
Hello from moduleInstallation
The second snippet has to use doLast (or its << shortcut) like the first snippet. Otherwise, the code is configuration code and will always be evaluated, no matter which tasks are eventually going to be executed. In other words, it's not the restoreFiles and restoreFromDate tasks that are being executed here (as one can tell from the bits of command line output that you don't show), but (only) their configuration code.
To better understand what's going on here (which is crucial for understanding Gradle), I recommend to study the Build Lifecycle chapter in the Gradle User Guide.
A)
task build << {
description = "Build task."
ant.echo('build')
}
B)
task build {
description = "Build task."
ant.echo('build')
}
I notice that with type B, the code within the task seems to be executed when typing gradle -t - ant echoes out 'build' even when just listing all the various available tasks. The description is also actually displayed with type B. However, with type A no code is executed when listing out the available tasks, and the description is not displayed when executing gradle -t. The docs don't seem to go into the difference between these two syntaxes (that I've found), only that you can define a task either way.
The first syntax defines a task, and provides some code to be executed when the task executes. The second syntax defines a task, and provides some code to be executed straight away to configure the task. For example:
task build << { println 'this executes when build task is executed' }
task build { println 'this executes when the build script is executed' }
In fact, the first syntax is equivalent to:
task build { doLast { println 'this executes when build task is executed' } }
So, in your example above, for syntax A the description does not show up in gradle -t because the code which sets the description is not executed until the task executed, which does not happen when you run gradle -t.
For syntax B the code that does the ant.echo() is run for every invocation of gradle, including gradle -t
To provide both an action to execute and a description for the task you can do either of:
task build(description: 'some description') << { some code }
task build { description = 'some description'; doLast { some code } }