Kotlin-dsl-samples: Provide a way to configure default kotlin plugins/artifacts version

[ligee]

Now the kotlin(module) functions for dependencies and plugins block either accept an explicit version of the module or take the version of the embedded kotlin distribution.

It would be helpful to provide a way to customize the default version, e.g. via the org.gradle.kotlin.dsl.default-kotlin-version (system) property.

[JLLeitschuh]

The current default is the version of kotlin that is being used to compile your Gradle Kotlin DSL files (I think). Is there a way to decouple these? Does it make sense to decouple these?

Can you compile your Gradle Kotlin DSL files with another version of Kotlin?

[gildor]

I would repeat my comment from Gradle channel in Kotlin Slack.

It looks strange for me that kotlin-dsl provides shortcut that specific only for Kotlin project (kotlin() or kotlinModule() before)

kotlin(“…”) method in kotlin-dsl is really convenient but forces you to use the wrong approach, because your project implicitly relates now on a version of Kotlin bundled to kotlin-dsl this approach doesn’t look like a recommended way to configure your project.
Of course, you can specify version explicitly, but I think most developers don’t do that.

if you use kotlin-gradle-plugin with new plugins DSL you can omit version as well and you always want to use the same version of the plugin with the same version of other kotlin dependencies.
Maybe better to move kotlin(“module”) extension to kotlin-gradle-plugin to allow use it. Looks like much better way to help configure project, actually it’s just additional helper function in plugin-specific DSL.

I thought that Gradle is not biased to any specific project type and I think it’s a good thing and kotlin-dsl should follow this strategy.

P.S. I very like idea of helper methods for project to reduce copy-paste of dependency ids and boiler plate extraction of dependency versions.
I would really want such thing in Android plugin for support-library dependencies. But it should be a part of plugin, not Gradle or kotlin-dsl API

My proposal to remove kotlin() method from kotlin-dsl and move it to Kotlin plugin.

[bamboo]

Thanks for the proposal, @gildor.

I've provided the rationale for the kotlin / kotlinModule dependency notation and embeddedKotlinVersion property in the original issue: #94.

[jmfayard]

Here is a proposal I made in slack

plugins {
    kotlin(module = "jvm", version = "1.1.4-3")
}
dependencies {
   // Currently: not giving a version implies embeddedKotlinVersion
  // Wanted: null implies using the kotlin plugin version, here 1.1.4-3 ... or else embeddedKotlinVersion
    compile(kotlin(module = "stdlib"))  
    compile(kotlin(module = "reflect"))
}

[gildor]

@bamboo Thanks, it's really big thoughtful discussion in #94
But I still think that kotlin() shortcut, indented to use mostly for Gradle Plugin developers is quite confusing for developers who just use Kotlin in their "not a gradle plugin" projects. Not because of shortcut itself, but because of versioning strategy.
I think the proposal from @jmfayard is good, at least it reduces possible confusion and accidental usage of embeddedKotlinVersion.

Yes, it's backward incompatible and probably break some builds, but better to do that before 1.0

As an alternative solution, maybe better to rename kotlin to localKotlin/embeddedKotlin, and continue to use of embeddedKotlinVersion under the hood. Of course, it was already proposed on #94, but maybe we should reconsider it again before 1.0
And such specific case as Gradle Plugin written on Kotlin shouldn't be more important than all other Kotlin project types, especially considering the fact that Gradle is most popular and the most supported build tool for Kotlin development.
Better to write small instruction for Gradle plugin authors than introduce such potentially confusing construct to kotlin-dsl.

[bamboo]

As an alternative solution, maybe better to rename kotlin to localKotlin/embeddedKotlin, and continue to use of embeddedKotlinVersion under the hood. Of course, it was already proposed on #94, but maybe we should reconsider it again before 1.0

Thanks, @gildor, we will reconsider this decision in our next planning meeting.

[eskatos]

We discussed this, acknowledged that the current situation is far from ideal and lead to some confusion.

Here's our plan.

We will leverage this:

Starting with Kotlin 1.1.2, the dependencies with group org.jetbrains.kotlin are by default resolved with the version taken from the applied plugin.
https://kotlinlang.org/docs/reference/using-gradle.html

By making the DependencyHandler.kotlin extension set a version on the dependency notation only if one is provided ; instead of defaulting to embeddedKotlinVersion ; effectively delegating the version choice to the Kotlin Gradle Plugin.

In practice this means that a build using the Kotlin DSL will not interfere with the desired behavior of the Kotlin Gradle Plugin that already "provides a way to configure default kotlin artifacts version" and will be the same as a build using the Groovy DSL. No more surprises.

We will keep the current behavior of the PluginDependenciesSpec.kotlin extension, that is defaulting to embeddedKotlinVersion while allowing to explicitely set a desired plugin version.

[eskatos]

We also introduced a DependencyHandler.embeddedKotlin(module: String) extension that provides the old behavior.

Closing as delivered in #511