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


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

plugins {

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, 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 {
    resolutionStrategy {
        eachPlugin {
            with (requested) {
                when ( {
                    "" ->
                    "androidx.navigation.safeargs.kotlin" ->

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

1 Like

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

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