-
Notifications
You must be signed in to change notification settings - Fork 431
Introduce embeddedKotlinVersion
property and kotlinModule
extension.
#94
Comments
Shouldn't this be more like the |
Possibly. The thing with Kotlin is that there are many libraries and at least one plugin for which you might want to pin down the version to the one shipped with Gradle. So instead of providing a different function for each - A What do you think? |
I think it could be that And then if you want to use additional libraries, you could add those explicitly with a version you pick or figure out programmatically. Is there an equivalent to I'm not saying this is better; it's just similar to what we're using with Groovy. It's not good that Groovy isn't a proper dependency when you use I know Groovy doesn't make strong guarantees about compiling with one version of Groovy and running with another. Does Kotlin have the same sort of guarantee? |
About Kotlin compatibility guarantees, we have this statement from the Kotlin 1.0 release announcement:
There is something equivalent to About |
Thanks, I think that mostly answers my compatibility question. If I were building a Kotlin project using the newest Kotlin-Gradle plugin but wanted to compile against the oldest Kotlin 1.0 stdlib, would that work? I guess you would need to be able to specify the compiler's version (separate from the plugin), which doesn't seem to be possible with a quick look at the docs. If I want to use an older Kotlin version, I shouldn't be forced to downgrade the version of the Kotlin-Gradle plugin too. And that shouldn't be a reason to expose a My inclination would be to be conservative, I say that because there are a few different scenarios with different "Kotlin versions" in play.
For 1) and 3), I think we want to encourage people to keep doing what they're doing. Add the Kotlin-Gradle plugin themselves and dependencies however they want. They shouldn't use I think a The most compelling reason for not having a Potentially, the more "helper" pieces are just a Kotlin-Gradle extension and not a part of gradle-script-kotlin at all. Gradle could provide the I think it's a good thing to encourage the separation between what Gradle ships with and what version of the Kotlin-Gradle plugin is being used. IOW, if Gradle shipped with an ancient version of the Kotlin-Gradle plugin, |
First of all, thanks for the deep thinking you are putting into this, @big-guy, it's been really helpful so far.
Absolutely. Although we currently don't ship and don't plan to ship the Kotlin-Gradle plugin that statement still makes sense when we replace Kotlin-Gradle plugin by Kotlin compiler which we do ship. Being able to compile with the very newest plugin will be desirable even when the version of the compiler shipped with Gradle is recent but not necessarily the very newest one. With regards to being able to compile your project against an older version of Kotlin or, more specifically, being able to use a version of I mostly agree with you on the different scenarios with different "Kotlin versions" in play. I partially disagree on scenario 3. I think it might be counterproductive to keep two Kotlin versions in mind - the one I use for automation and the one I use for the application. I think one language to rule them all is a better value proposition so I want to make it easier for people to follow that route and that also includes the ability to upgrade About
It is the version of Kotlin embedded in gradle-script-kotlin so I think we might mitigate the confusion by choosing a better name ( |
No worries.
I'm not really talking about the
For 1), I very strongly think we should separate the version of Kotlin that comes with Gradle with the version that someone uses in their project. Let's say we didn't have For 2), it's the same as above only someone may decide that they only support the version of Gradle that their plugin is built with (and use 1 and 2) also get messy because there could be three Kotlin versions that are in play. Your For 3), it makes less sense to use external coordinates since the buildSrc project is tightly coupled to a particular version of Gradle (you're not going to reuse buildSrc for other projects). You want to use the version of Kotlin that is being used by Gradle for the build scripts. I'm glad I got you to think of something different :) I really think the helpers to construct dependency coordinates are not a feature of What's the use case for upgrading |
In general the reasons are the same for why you would like to upgrade to a new version of any plugin separately from Gradle. You might want to take advantage of some new feature and don't want to wait. Your build might depend on some specific quirk of a Gradle component and upgrading just this single module is less risky. In the particular case of
Fully agreed.
I don't disagree. It's just far easier to add it to
And I'm not planning to make that any harder than it is Today. This is only about making it easier to go with the one language to rule them all flow, particularly in the months leading up to 1.0 GA as both Kotlin 1.1 and GSK mature. |
Yes. And this level of sophistication will probably require more isolation than we currently provide. Something to keep in mind. |
localKotlinVersion
propertyembeddedKotlinVersion
property
embeddedKotlinVersion
propertyembeddedKotlinVersion
property and kotlinModule
extension.
To allow plugins and buildSrc code to be compiled against the version of Kotlin shipped with Gradle.
The text was updated successfully, but these errors were encountered: