Are there any plans to use Gradle Properties/Providers everywhere as input for the current dsl/task/...

# gradle

[hfhbd]

Are there any plans to use Gradle Properties/Providers everywhere as input for the current dsl/task/extensions? The upcoming Kotlin 2.0 sounds like a perfect change, but the 2.0.0-Beta3 still does not support lazy types/inputs everywhere.

[ephemient]

I'd like that too, but

The upcoming Kotlin 2.0 sounds like a perfect change

why? the major version number doesn't signify a major change of anything other than K2

[hfhbd]

I would expect breaking source changes (T vs Property<T>) in a major release than in a minor release.

[tapchicoma]

there any plans to use Gradle Properties/Providers everywhere as input for the current dsl/task/extensions?

We are moving to this direction, but gradually. Do you have some exact place in mind where you want to use property?

[hfhbd]

Sure, I do have many use-cases, but at the moment I want to set the version of NodeJsRootExtension calculated by another file property. Of course I can use get here too, but I want to avoid it.

[tapchicoma]

cc @Ilya Goncharov [JB]

[hfhbd]

I looked up the sources if there was a change on master for an upcoming release, and I honestly don't understand your grateful migration, eg https://github.com/jetbrains/kotlin/commit/7b409d050588332c51e1c60b042a70033823a747#diff-bd90527030378bb68a4f4eebf1914f6251c39ce9e1f127151a987323ac3ba3a6
A Provider can hold null, if its value is not present, so it's strange to make the declaration nullable, or in other locations, the provider nullable.

[hfhbd]

And why do you only change one input parameter and not all if you already refactor the class? 😅

[Ilya Goncharov [JB]]

To get rid of exponential expand of scope of changes. In every refactoring you have to know where to stop to refactor 🙂
And yes, such extensions should be migrated onto Gradle’s Property API

[hfhbd]

Okay, then I will provide a PR

[ephemient]

I would expect breaking source changes in a major release than in a minor release

2.0 was not meant to be externally any more major than other major releases like 1.9, https://blog.jetbrains.com/kotlin/2023/02/k2-kotlin-2-0/

[hfhbd]

FYI: https://youtrack.jetbrains.com/issue/KT-65639/Gradle-JS-version-of-NodeJsRootExtension-has-no-lazy-property

[tapchicoma]

I would expect breaking source changes in a major release than in a minor release

We try to have a proper deprecation cycle when possible and only have breaking changes if there is not other way around. Gradle is already complex thing to break user projects in every major Kotlin release.