Sqldelight: Gradle plugin cannot be applied via plugins DSL due to missing plugin marker artifact

[Nimrodda]

Currently it is not possible to apply SQLDelight Gradle plugin using Gradle Plugins DSL.
I inspected the artifacts published to Maven Central and found out that there's no plugin marker artifact, which is normally created and published by Java Gradle Plugin development plugin that I see is indeed used here.

As a workaround, I configured gradle.settings to handle this case specifically, which isn't nice:

// must be the topmost block in the file
pluginManagement {
    repositories {
        mavenLocal()
        mavenCentral()
        jcenter()
        google()
        gradlePluginPortal()
    }
    resolutionStrategy {
        eachPlugin {
            if (requested.id.id == "com.squareup.sqldelight") {
                useModule("com.squareup.sqldelight:gradle-plugin:1.2.0")
            }
        }
    }
}

I thought it might be due to the way you publish the plugin, i.e. using the old maven Gradle plugin instead of the newer maven-publish plugin, but unfortunately after cloning the repo and changing it to maven-publish and installing it locally, I still don't see the plugin marker artifact in the local maven repository so should be something - somewhere that overrides the standard behavior.

[gildor]

Duplicate of #570

[LouisCAD]

This is not a duplicate of #570 because the plugin marker artifact doesn't require publishing on the gradle plugin portal.
This issue is an easy fix and should be addressed before considering publishing on the gradle plugin portal.

[gildor]

Yes, good point. But still, the original issue will not be fixed even with plugin marker, marker allows to get rid of only from resolutionStrategy block, but pluginManagement still required

[LouisCAD]

I prefer to not have to define a resolutionStrategy for EACH plugin I want to use.

If all plugins correctly define a plugin marker, you just need to add the repos in the pluginManagement, which are usually share among several libraries/plugins, which is something we already do for regular dependencies.