tim
02/25/2020, 3:43 PMCasey Brooks
02/25/2020, 3:57 PMJavaExec
task in Gradle (https://docs.gradle.org/current/dsl/org.gradle.api.tasks.JavaExec.html#org.gradle.api.tasks.JavaExec:environment). the JVM has no support for setting variables at runtimetim
02/25/2020, 4:17 PMCasey Brooks
02/25/2020, 5:15 PMval run by tasks.getting(JavaExec::class) {
environment["myFlag"] = true
}
tim
02/25/2020, 5:40 PMtim
02/25/2020, 5:42 PM./gradlew run
from the cli but not when i launch from inside intellij 🤯Casey Brooks
02/25/2020, 5:48 PMtim
02/25/2020, 7:01 PMtim
02/25/2020, 7:43 PMval run by tasks.getting(JavaExec::class) { ... }
. Does it modify the JavaExec class by executing { ... }
before other calls? So that when JavaExec run later it has been modified? Does this then mean if i had multiple run commands they are all modified?
Sorry brand new to gradle and struggling to wrap my head around itCasey Brooks
02/25/2020, 7:53 PMval run by tasks.getting
looks up a task that has already been added by one of your Gradle plugins (from plugins { ... }
), and then executes the lambda to configure that instance. This method specifically looks for a task named run
(the variable name) of the given type (JavaExec
). You may have multiple JavaExec
tasks, and each one of them can be configured independently in a similar way. There are also facilities for configuring all tasks of a single type with one lambda (such as tasks.withType<KotlinCompile>().configureEach { ... }
).
I’m not sure exactly when it gets configured during the entire build lifecycle, and you generally don’t need to care about that. You can just feel safe knowing that the task gets configured at some point before it is executed. There’s a bunch of default configurations on it already, or other plugins may configure it, but I believe the configuration you apply in the buildscript takes precedence over all thattim
02/25/2020, 7:58 PMtim
02/25/2020, 8:01 PMCasey Brooks
02/25/2020, 8:06 PMtim
02/25/2020, 8:07 PMtim
02/25/2020, 8:08 PM