Migrating maven-publish to a custom Kotlin (1.6.20+) plugin

Help/Discuss
1

I have over a dozen independent projects that duplicate this build logic:

plugins {
    ...
    id("maven-publish")
    ...
}
...
publishing {
    publications {
        create<MavenPublication>("maven") {
            ...
        }
    }
}

so it is becoming compelling to move this duplicated build logic to a custom plugin. Using the kotlin-dsl plugin allows me to simply cut-paste the publishing configuration block to the new custom plugin. Nice. But the kotlin-dsl plugin only works with Kotlin up to 1.5.31 and I must have bleeding edge access (Jetpack Compose) to Kotlin 1.6.20 and later. So I have started to migrate the configuration block and have hit a road block with this code:

private fun Project.configurePublishing(pajatoExtension: PajatoExtension): PublishingExtension {
    extensions.getByType(PublishingExtension::class.java).let {
        publications {
            it.add(create<MavenPublication>("maven") {

since I cannot seem to import the correct create function as IntelliJ offers up hundreds of choices. A link or explicit import statement would be much appreciated. Or any other guidance for that matter, perhaps a different approach.

This seems to be promising:

private fun Project.configurePublishing(pajatoExtension: PajatoExtension): PublishingExtension {
    extensions.getByType(PublishingExtension::class.java).let {
        publications {
            val publication = it.create<MavenPublication>("maven") {
                ...
            }
            it.add(publication)

but I would still like someone who knows Gradle better than I do to weigh in as to whether this is a good, bad or indifferent approach.

2

You must not confuse the Kotlin version used for your build logic / plugin and the Kotlin version used in your production code.
You actually cannot (or at least should not and if you do don’t wonder about problems) use any other Kotlin version than is shipped with the Gradle version for your build logic. The Gradle version applying your plugin dictatest the Kotlin runtime with which your plugin is run.

3

Besides that, the kotlin-dsl free variant would be

extensions.configure(PublishingExtension::class.java) {
    publications {
        create("maven", MavenPublication::class.java) {
            ...
        }
    }
}
4

This sounds important so I’d better understand it.
My assumption is that the version of Kotlin that I specify in the project being built is the version of Kotlin that will run the tests as part of the build. For my use case, that is 1.6.20. If I use the kotlin-dsl plugin, I seem to recall, Gradle will issue a complaint, possibly an error, that 1.5.31 is the highest Kotlin version supported by that plugin.
With this context, the build and production Kotlin versions are one and the same (actually production might use a higher version, which is reasonable). Bottom line to me is that the Kotlin version must support the test code first and plugins second. From that I conclude kotlin-dsl is, unfortunately, not available to me.
Am I still missing something important?

5

Tests are not run “as part of the build”, that would mix up class paths and be pretty stupid actually.
Tests are even not run in the same JVM but in dedicated test worker processes iirc.
The classpath of the tests has as little in common with the classpath of a Gradle plugin you use as the classpath of the production code has.