skip to content

Why are plugin repositories configured in pluginManagement separate from dependencyResolutionManagement, and how do the two settings blocks relate?

level: middleimportance: should knowfreq 44%

answer

  1. pluginManagement = plugin repos
  2. dependencyResolutionManagement = dependency repos
  3. separate lists, not shared
  4. pluginManagement first in file
  5. default plugin repo = gradlePluginPortal()

basics

~10 s

pluginManagement.repositories says where to find plugins; dependencyResolutionManagement.repositories says where to find project dependencies. They are different concerns, so Gradle keeps them in separate settings blocks.

solid answer

~30 s

Both blocks live at the top of `settings.gradle(.kts)`, but they govern different things. `pluginManagement { repositories { } }` lists the repositories Gradle searches to resolve **plugins** (the build-tooling classpath). `dependencyResolutionManagement { repositories { } }` lists repositories for **project dependencies** (the code your app compiles against). They are intentionally separate because a plugin often comes from `gradlePluginPortal()` while application dependencies come from `mavenCentral()` or a company repo — and you may want different access rules for each. As a structural matter, `pluginManagement` comes first in the file; `dependencyResolutionManagement` follows. If you omit `pluginManagement.repositories`, Gradle defaults to `gradlePluginPortal()`.

code

kotlin · 11 lines
kotlin
// settings.gradle.kts
pluginManagement {
    repositories { gradlePluginPortal() }          // for PLUGINS
}

dependencyResolutionManagement {
    repositories { mavenCentral() }                // for DEPENDENCIES
}

rootProject.name = "svc"
include("api", "domain")

go deeper

for a junior

Know one block is for plugins, the other for dependencies.

for a middle

Explain that the repo lists are independent and give the correct file ordering plus the gradlePluginPortal() default.

for a senior

Discuss governance: restricting plugin sources separately from dependency sources, repositoriesMode enforcement.

for a principal

Set org-wide policy: vetted internal plugin portal, FAIL_ON_PROJECT_REPOS, supply-chain control across both blocks.

## Two different classpaths A Gradle build deals with two distinct sets of artifacts: 1. **The plugin classpath** — the jars that implement build logic (the Kotlin plugin, Spring Boot plugin, etc.). These are resolved during initialization/configuration and run *inside* Gradle. 2. **The project (production/test) classpath** — the libraries your application actually depends on (`implementation`, `testImplementation`, …). These come from potentially different places and have different trust/governance requirements, so Gradle gives each its own settings block. ## pluginManagement.repositories Configured inside `pluginManagement {}`, this list is searched when resolving plugins requested via the `plugins {}` DSL. If you do not configure it, the **default is `gradlePluginPortal()`**. ```kotlin pluginManagement { repositories { gradlePluginPortal() mavenCentral() } } ``` ## dependencyResolutionManagement.repositories A sibling top-level block (declared *after* pluginManagement) that centralizes where **project dependencies** are fetched, often with `repositoriesMode` set to fail the build if a subproject declares its own repositories: ```kotlin dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() } } ``` ## How they relate structurally - File order: `pluginManagement` first, then `dependencyResolutionManagement`, then `rootProject.name`, then `include(...)`. - Both are settings-script-only constructs; neither belongs in a build script. - They do **not** share repository lists. A repo declared for plugins is not automatically used for dependencies and vice versa. ## Why the separation is useful - **Security/governance:** you can restrict the plugin source to a vetted internal portal while allowing a broader set of dependency repos (or the reverse). - **Clarity:** mixing them would make it ambiguous whether a repo is for tooling or for app code. (Note: the *semantics* of plugin resolution — how the portal is queried, resolutionStrategy rewrites — are a plugin-resolution topic; here the point is the structural separation of the two settings blocks.)

  • If you declare mavenCentral() only in dependencyResolutionManagement, can plugins be resolved from it?
    No. Plugin resolution uses only pluginManagement.repositories. The two repository lists are independent.
  • What is the default plugin repository if pluginManagement.repositories is omitted?
    gradlePluginPortal().

saying these in an interview costs you the question

  • Assuming the two blocks share one repository list
  • Putting dependencyResolutionManagement before pluginManagement
  • Thinking project dependency repos are searched for plugins

context

resolving links…