This message was deleted.
# kotlin-dsl
s
This message was deleted.
j
If that doesn't work maybe you need to add
@Optional
Copy code
abstract class MyTask : DefaultTask() {

    @Option(option = "console", description = "")
    @Input
    @Optional
    val taskOption: String = "plain"

    @TaskAction
    fun action() {
        // My action
    }
}
s
that doesnโ€™t seem to have an effect unfortunately ๐Ÿ˜ž
n
The console option applies to the entire gradle build, and is set before any configuration phase in gradle is being executed. So specifying it in your task will not change it. I'm pretty sure you can't change the behaviour in the context of a single task.
๐Ÿ˜ž 1
j
I haven't tried to set default values, but with nullables it is working for me, for example:
Copy code
@Input
    @Option(option = "added", description = "Add an item to the `added` section")
    @Optional
    public val added: Property<String?> = objects.property()
Maybe you can check if it is
null
and use a default value based on that.
s
seems like it is not possible for this use case as Niels mentioned ๐Ÿ˜ž thanks for the help ๐Ÿ™
j
I mean, your use case is working for me, but instead of setting the default values to the property, I check if it is set or not, and there you can set the default value
Running
./gradlew myTask
would mean that
taskOption
is null, so you can check that and use a different value inside the
@TaskAction
function
s
--console=plain
is intended to change the console output which was my intention, passing the option to the task would work but it would not affect the console output
j
Ah, I misunderstood your problem
s
no worries ๐Ÿ˜„ thanks for the help anyways ๐Ÿ™
๐Ÿ™‚ 1
n
Why do you want this though? Perhaps there's a different angle to achieve what you want?
s
i would like to use the
--console=plain
option because my task would require user input which becomes quite unclear with the โ€œregularโ€ mode. The reason i want it built in is for better user experience, it is much more convenient to just need to type the task name
n
hmm, I tried to set up gradle tasks with user input in the past and quickly abandoned that idea. It's really better to have them run with options for those tasks, and just spit out some error messages when they don't supply the values.
and/or build a cli tool around the gradle invocation that takes the inputs and then just invokes the gradle build you need
s
ah okay, my idea with this was to support simple inputs (yes/no) that just define if the build should proceed or not, so far it has worked. What kind of issues have you encountered that i should think about if i go down this path?
n
https://github.com/gradle/gradle/issues/2842 There's this issue (and others linked from it) that explain some of the pitfalls. I think in our case it was mostly the interaction with external tools and their usage of
System.console
that made me abandon the idea, but it's been a while. So I might just be completely misremembering ๐Ÿคท
๐Ÿ™Œ 1
s
ah okay! thanks for this, really helpful ๐Ÿ™Œ