I've got a main build.gradle script which employs tasks in a secondary script.
If possible I'd like a task in the secondary script to depend upon one in the primary one. But it seems that's not possible. Or is it?
In a.gradle:
...
apply from: 'b.gradle'
task inA {
}
...
In b.gradle:
task inB {
dependsOn inA
}
This give:
A problem occurred evaluating script.
Could not find property 'inA' on task ':app:inB'.
Is this possible to do?
Build scripts are evaluated sequentially (top to bottom) so in this case task 'inA' doesn't exist yet when 'b.gradle' is applied. Simple fix is to use strings instead of symbols when referring to a task.
task inB {
dependsOn 'inA'
}
Related
Whilke going through the book I came across this line
Groovy automatically exposes an implicit variable named it to indicate
the loop iteration index.
from the Gradle in Action book, chapter 2 Listing 2.1
The line says that $it represents loop iteration index. However when I try add
$it to println statement of task yayGradle0/1/2, it prints out the task and not the index. I'm confused about this behavior. Please guide.
3.times{
task "yayGradle$it" <<{
println 'Gradle rocks--->>>'+"$it"
}
}
The output after running task yayGradle0 is :
Gradle rocks--->>>task ':yayGradle0'
You are using the it variable in a different context than presented in the book. In your case you are working in the context of the task's Closure. Therefore, it represents a different object, a org.gradle.api.Task instance. It would be helpful to reference Closure delegation strategies. Please also see Appendix B in the book.
(edit after rereading)
it is the index in loop.
From groovy shell
3.times {
println "${it}"
}
0
1
2
In your code there is another closure, it becomes variable to that closure (which is task name)
Following example uses explicit variable at top level.
3.times{ counter->
task "hello${counter}" <<{
println 'Gradle rocks--->>>'+" ${it} ${counter}"
}
}
$gradle hello2 gets following output.
Task :hello2
Gradle rocks--->>> task ':hello2' 2
references
novice
groovy closures
I've been struggling with this for a day and a half or so. I'm trying to replicate the following Ant concept in Gradle:
<target name="test">
...
<runexe name="<filename> params="<params>" />
...
</target>
where runexe is declared elsewhere as
<macrodef name="runexe" >
...
</macrodef>
and might also be a taskdef or a scriptdef i.e. I'd like to be able to call a reusable, pre-defined block of code and pass it the necessary parameters from within Gradle tasks. I've tried many things. I can create a task that runs the exe without any trouble:
task runexe(type: Exec){
commandLine 'cmd', '/c', 'dir', '/B'
}
task test(dependsOn: 'runexe') {
runexe {
commandLine 'cmd', '/c', 'dir', '/N', 'e:\\utilities\\'
}
}
test << {
println "Testing..."
// I want to call runexe here.
...
}
and use dependsOn to have it run. However this doesn't allow me to run runexe precisely when I need to. I've experimented extensively with executable, args and commandLine. I've played around with exec and tried several different variations found here and around the 'net. I've also been working with the free books available from the Gradle site.
What I need to do is read a list of files from a directory and pass each file to the application with some other arguments. The list of files won't be known until execution time i.e. until the script reads them, the list can vary and the call needs to be made repeatedly.
My best option currently appears to be what I found here, which may be fine, but it just seems that there should be a better way. I understand that tasks are meant to be called once and that you can't call a task from within another task or pass one parameters but I'd dearly like to know what the correct approach to this is in Gradle. I'm hoping that one of the Gradle designers might be kind enough to enlighten me as this is a question asked frequently all over the web and I'm yet to find a clear answer or a solution that I can make work.
If your task needs to read file names, then I suggest to use the provided API instead of executing commands. Also using exec will make it OS specific, therefore not necessarily portable on different OS.
Here's how to do it:
task hello {
doLast {
def tree = fileTree(dir: '/tmp/test/txt')
def array = []
tree.each {
array << it
print "${it.getName()} added to array!\n"
}
}
}
I ultimately went with this, mentioned above. I have exec {} working well in several places and it seems to be the best option for this use case.
To please an overzealous moderator, that means this:
def doMyThing(String target) {
exec {
executable "something.sh"
args "-t", target
}
}
as mentioned above. This provides the same ultimate functionality.
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.
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 } }