I have a simple question, but I can't seem to find...
# community-support
a
I have a simple question, but I can't seem to find a simple answer. Maybe it doesn't exist. I have the
application
plugin installed. Is it possible to add a new task
runDev
that uses the normal
run
task, but passes command-line variables to the Kotlin/Java main function?
Well, that was easy:
Copy code
tasks.register("runDev") {
    group = "application"

    val originalTask = tasks.getByName("run") as JavaExec

    originalTask.args("-config=application-dev.conf")

    dependsOn(originalTask)
}
s
I would just create a separate JavaExec task and configure it in whatever way needed. Having the initialization of one task change another task looks like a smell to me, because if you now execute e.g.
gradle run runDev
then it will only run the application once and not twice.
you could also add the args in
run
conditionally based on some Gradle property passed to the build.
a
But imho it is a code smell if I have to duplicate everything that is in the normal run task. Just take a look at the run task of the “application” plugin. It is quite a lot. I only want to add a runtime parameter. It shouldn’t be that I need to duplicate code for that or have to look up the source of a task in Git
And why would I want to run Gradle run rundev? It doesn’t make sense.
Passing a property via the commandline also works via —args, but it defeats the purpose where I want to have development tasks in Gradle and not rely on either IntelliJ run configurations or some Makefile to structure my tasks
v
Sergej was imho a bit too diplomatic. What you do is not a code smell, it is simply wrong and does only sometimes maybe what you intend. If for whatever reason the
runDev
task is configured (only configured, not executed), then the
run
task always has that parameter. So if you for example apply some (granted, misbehaving, but some plugins do) plugin that does some bad things like
tasks.all { ... }
, then the
runDev
task is always configured and thus the
run
task does always have that parameter, to only describe one of the problematic situations. The main question is your use-case. For example do you want to be able to run both variants in one Gradle execution? If yes, then having two tasks (but don't properly) makes sense. But if you always want to only run one of those variants, it makes much more sense to conditionally configure that one task and not add another task. For example something like
./gradlew run -P runType=dev
. And if a given person would practically always use that mode or at least most of the time, he could also simply set that property in his
<GRADLE_USER_HOME>/gradle.properties
file.
And to answer the original question, no, not really. One task cannot call another task. One task can depend on another task. But cross-configuring one task from the configuration of another task like in your self-reply is a very bad idea.
a
@Vampire thanks for the clear explanation. That makes sense. It is very important to me to understand the why of it all. And this is clear. Thanks!