This message was deleted.

There is no issue, as that is expected. If you build a convention plugin that applies another plugin, the project building that plugin needs to depend on that plugin for the production code of the plugin. You actually can use the plugin id though like

<plugin id>:<plugin id>.gradle.plugin:<plugin version>

. If you use the plugin exclusively in the convention plugin, just add it as a normal lib entry in the version catalog. Or you can extract the plugin id and version from the accessor and build up the syntax I mentioned. And of course there is https://github.com/gradle/gradle/issues/17963 to thumbs up and follow.

Yeah I suspected that was intended and with issue I also meant feature request in case it is intended, so thanks for the link! Interesting point about the strict format of the plugin artifacts, thanks for that info :)

Those are what the docs call "marker artifact" and which are the way how a plugin id in the plugins block is mapped to an actual dependency

You can define the plugin in the version catalog as a ‘plugin’ and reference that in the dependencies block using extension functions to build up the syntax:

public fun DependencyHandlerScope.plugin(id: String, version: String): String =
    "$id:$id.gradle.plugin:$version"

public fun DependencyHandlerScope.plugin(plugin: Provider<PluginDependency>): Provider<String> =
    plugin.map { "${it.pluginId}:${it.pluginId}.gradle.plugin:${it.version}" }

settings.gradle.kts

plugin("nullaway", "net.ltgt.nullaway").version("1.3.0")

build.gradle.kts

implementation(plugin(libs.plugins.nullaway))