Drop kotlin-dsl plugin

[3flex]

Using the kotlin-dsl plugin creates additional implicit dependencies on the Kotlin version used by Gradle as seen in #258 (comment).

Removing the use of kotlin-dsl in the plugin itself removes that dependency. Now the Kotlin version required by the project can be set independently and is not tied to the Kotlin version used by the Gradle version applied to the wrapper.

[Vampire]

What the kotlin-dsl plugin does is:

• it checks that the expected version for the current Gradle version is applied
• it applies the built-in java-gradle-plugin
• it applies the kotlin-dsl-base plugin
  • this applies the built-in embedded-kotlin plugin (which complains if you bring in a different KGP version than the built-in where built-in is defined by the kotlin-dsl plugin)
  • adds the kotlinDslPluginOptions extension with the only option to set the jvmTarget which defaults to 1.8
  • adds the gradleKotlinDsl() dependency to compileOnly and testImplementation
• it applies the PrecompiledScriptPlugins plugin
  • this does nothing if there are no **/*.gradle.kts files in the plugin source set

So shouldn't it be sufficient to just apply the built-in version of kotlin-dsl and set the languageVersion and / or apiVersion to the versions used by the lowest supported Gradle version?
Or if these versions are not supported by the Gradle version of this project, either downgrade Gradle, or force the Kotlin Gradle Plugin to a version where those values are still supported, ignoring the warning that the Kotlin version does not match the embedded version, but still using the built-in kotlin-dsl version?

[TWiStErRob]

@Vampire thank you for chiming in!

So shouldn't it be sufficient to just apply the built-in version of kotlin-dsl and set the languageVersion and / or apiVersion to the versions used by the lowest supported Gradle version?

The problem is that when using Gradle 8.3 to compile the nexus plugin the embedded Kotlin compiler (via kotlin-dsl) does not support the 1.3 language version required for the minimum Gradle version supported by nexus plugin. That's a long sentence, here's a ref: gradle/gradle#25868

Or if these versions are not supported by the Gradle version of this project, either downgrade Gradle

We're here. We're stuck on 8.2.1. This PR tries to unblock the sticky situation, without warnings.

or force the Kotlin Gradle Plugin to a version where those values are still supported, ignoring the warning that the Kotlin version does not match the embedded version, but still using the built-in kotlin-dsl version?

In #258 I think I did this, but maybe it could be done better.

[TWiStErRob]

@szpak I'm more and more in favour of just getting this in, to move things along. It's easy to reinstate anything here, after we're on 8.6, or maybe we won't even miss them :) This might even be a non-issue if we drop more Gradle versions post 2.0.

[szpak]

This might even be a non-issue if we drop more Gradle versions post 2.0.

What version would you like to set as a minimum for 2.0?

[TWiStErRob]

What version would you like to set as a minimum for 2.0?

Post 2.0 = 2.1+ or 3.0. I think we dropped enough with #274. Let's try to make a release, it's been too long. I have a feeling projects are forced to use 2.0.0-rc-1 if they want full Gradle 8.+ compatibility. Note: the open PRs shouldn't change any compatibility afair, so it's not necessary to include them in the release.

[szpak]

Let's try to make a release, it's been too long.

Fair point.

1. Do we want to merge also Gradle 8.5 #296 before? Or this also is the one you think could/should be postponed?
2. Would you propose rc-2 to be open for a week or so to gather potential complaints? Or directly "final"?

[szpak]

@TWiStErRob Feel free to merge it once you think it is ready.

[TWiStErRob]

• This unblocks Gradle 8.5 #296, but but we're still blocked on chore(deps): update plugin org.jetbrains.kotlin.jvm to v1.9.22 #299 (comment)