https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# kotlin-dsl
s
This message was deleted.
v
Can you maybe show what you tried and what does not work?
Besides that this channel is more about 
kotlin-dsl
in build scripts and precompiled script plugins than general plugin development in Kotlin. 😉
l
Sorry. Maybe the channel description could say that. Should I move the question to #CA7UM03V3?
#CAHSN3LDN might be better actually
v
#CA745PZHN I'd say, but just remember it for next time 🙂
l
Sorry, I don't post here often. Thanks for the information. Back on topic, I tried the following:
Copy code
public open class MyTask: DefaultTask() {
    @Option(option = "param", description = "...")
    public var param: String = ""

    @set:Option(option = "param2", description = "...")
    public var param2: String = ""

    @Option(option = param3, description = "...")
    public fun setParam3(value: String) { ... }
}
And for `@OutputFile', I tried:
Copy code
@OutputFile
    public val outputFile: RegularFileProperty = project.objects.fileProperty().convention(
        RegularFile { File("...") }
    )
Ah, I found the problem for 
@Option
v
The latter is a trap you fell into like me too in the past. You cannot implement 
RegularFile
like that. It just looks like a functional interface, but you cannot do it like that. Regarding the option, iirc, I'd recommend you make it a 
val
and 
Property<String>
and then annotate the getter with 
@get:Option
And you can also make the class and the properties 
abstract
, then you don't need to initialize them, but Gradle will decorate it accordingly for you
l
@Option
was working in the included build, but I was calling it from the project
What's the alternative to implement 
RegularFile
? 
object : RegularFile { override... )
?
v
You don't implement it ever. You get it from some API. For example 
layout.buildDirectory.file("foo")
. Or to set a 
RegularFileProperty
you can also give it a 
File
if you have one. But make sure to never anywhere call the 
File
constructor with a relative path. That is bad in almost all situations, not only in a Gradle build, because it depends on the current working directory of the user. And in case of a Gradle build that is often the project directory, but this is not guaranteed and not always the case. You just make the build flaky and unreliable with that. 
layout.projectDirectory.file("foo")
is for example better.
l
All right, thanks a lot for your help
👌 1
4 Views
Open in Slack
PreviousNext
Powered by