-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kotlin DSL: property names containing dots cannot be looked up through property delegation #12865
Comments
It can contain more than a property. For instance, it might find a task: val test: Task by project
println(test) Just wondering: do you already have a plugin / DSL for properties? In my experience:
So far I've settled on https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/gradle-extensions-plugin#typed-project-property-accessor which is used like the following: val skipCheckstyle by props()
val skipAutostyle by props()
val skipJavadoc by props()
val enableMavenLocal by props()
val enableGradleMetadata by props()
...
if (project.props.bool("junit4", default = false)) {
testImplementation("junit:junit")
testRuntimeOnly("org.junit.vintage:junit-vintage-engine")
} |
Ah, I was not aware of that! That's way too obscure, and it goes against the more explicit nature of Kotlin. I think it wouldn't hurt to enforce explicitness instead: val test: Task by project.task() I didn't build anything myself, and I'm just working around it ad hoc. I appreciate that there are available plugins, but this looks like a core limitation that should be addressed in the DSL itself. |
I think you could use |
The documentation of the Kotlin DSL described the use of delegated properties to look up project properties:
The property lookup is hardcoded to use the Kotlin value name as the name of the property, which precludes the use of dots in the name, even with backticks (as specified in the grammar). Also, I'd argue that this use of a property delegate is somewhat obscure, since it doesn't express that the value is acquired from a property. I think that something like this would be more readable and flexible:
Also, it would be nice for the delegate to parse string values into primitive types – boolean and integer in particular are frequently used.
The text was updated successfully, but these errors were encountered: