How does the Plugin DSL resolve to a dependency in the classpath?

Help/Discuss
1

Greetings!

I would love to understand how the plugin resolution works when using the plugins DSL. Consider the following plugin block from a subproject:

plugins {
    id("org.springframework.boot")
    id("io.spring.dependency-management")
}

Provided that the versions are given somewhere else in the parent project, how does the first plugin know that it must look for org.springframework.boot:spring-boot-gradle-plugin in the classpath? Is there any function I can call? Same goes for the second with io.spring.gradle:dependency-management-plugin?

For reference, I found those dependency notations by searching the plugin ids in question at https://plugins.gradle.org, and then looking at their respective legacy buildscript block.

Consequently, is there an easy way to avoid those verbose useModule() calls in a settings.gradle.kts script?

pluginManagement {
    repositories {
        gradlePluginPortal()
        google()
    }
    resolutionStrategy {
        eachPlugin {
            with (requested) {
                when (id.id) {
                    "com.android.application" ->
                        useModule("com.android.tools.build:gradle:$version")
                    "androidx.navigation.safeargs.kotlin" ->
                        useModule("androidx.navigation:navigation-safe-args-gradle-plugin:$version")
                }
            }
        }
    }
}

Thank you in anticipation for any help you’ll be able to provide me with. It is genuinely appreciated.

1 Like
2

This is handled by plugin marker artifacts and is explained in this section of the docs: Plugin Marker Artifacts. If the repository has the correct plugin marker artifacts (or you can publish your own to a private repository group), you don’t need anything special in your settings.

1 Like
3

Thank you for your quick answer: that was definitely the concept I was looking for.