skip to content

How does pluginManagement differ from dependencyResolutionManagement, and how do they coexist in settings?

level: middleimportance: should knowfreq 44%

answer

  1. plugins vs libraries — two channels
  2. separate repository lists
  3. pluginManagement first, then dependencyResolutionManagement
  4. repositoriesMode FAIL_ON_PROJECT_REPOS (dep side)
  5. same DSL shape, different job

basics

~10 s

pluginManagement configures repositories and rules for resolving Gradle plugins; dependencyResolutionManagement configures repositories for resolving library dependencies. They are separate settings blocks with separate repository lists.

solid answer

~30 s

Both are settings-level blocks, but they govern two different resolution channels. `pluginManagement {}` controls where **plugins** (`plugins { id(...) }`) are fetched and how their versions resolve. `dependencyResolutionManagement {}` controls where **library dependencies** (`implementation("...")`) are fetched, and can centralize repositories for all projects (via `repositoriesMode`). Their repository lists are independent: declaring `mavenCentral()` for plugins does not make it available for dependencies. Ordering-wise, `pluginManagement {}` must be first; `dependencyResolutionManagement {}` comes after it (but before/after `include` is flexible). A common, clean settings file declares plugin repositories in `pluginManagement`, then library repositories in `dependencyResolutionManagement` with `repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)` to forbid per-project repository drift.

code

kotlin · 7 lines
kotlin
pluginManagement {
    repositories { gradlePluginPortal(); mavenCentral() }  // for plugins
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories { mavenCentral() }                        // for libraries
}

go deeper

for a junior

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

for a middle

Explain that the repository lists are independent and describe a correct settings layout with both blocks.

for a senior

Add repositoriesMode for centralizing dependency repos and discuss the trust-boundary rationale for separating the two.

for a principal

Treat both blocks as the settings-level governance surface controlling provenance of all plugins and libraries across the build.

## Two resolution channels Gradle resolves two distinct kinds of things, through two distinct mechanisms: 1. **Plugins** — requested in `plugins { id("...") version "..." }`. Configured by **`pluginManagement {}`**. 2. **Library dependencies** — requested in a build script's `dependencies {}` (e.g. `implementation("org.springframework:spring-core")`). Configured by **`dependencyResolutionManagement {}`** (or per-project `repositories {}`). Each has its **own** repository list. A repository you add for plugins is *not* automatically used for dependencies, and vice versa. This separation is intentional: plugin provenance and library provenance are different trust decisions. ## Side-by-side settings file ```kotlin // settings.gradle.kts pluginManagement { repositories { gradlePluginPortal() mavenCentral() } } dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() } } rootProject.name = "app" include(":core", ":web") ``` ## Ordering `pluginManagement {}` must be the **first** block. `dependencyResolutionManagement {}` follows. The two never merge their repository lists. ## repositoriesMode (dependency side only) `dependencyResolutionManagement` adds something `pluginManagement` doesn't emphasize: `repositoriesMode`. With `FAIL_ON_PROJECT_REPOS`, any subproject that declares its own `repositories {}` causes a build failure, forcing all dependency repositories to be centralized in settings. There is no exact analog for plugins because plugin repositories are inherently centralized in `pluginManagement` already. ## Why people confuse them Both contain a `repositories {}` block with identical-looking calls (`mavenCentral()`, `maven {}`). The block they sit in determines whether those repositories serve **plugins** or **dependencies**. Misplacing a repository — e.g. expecting a plugin to resolve from a repo declared only in `dependencyResolutionManagement` — yields a *plugin not found* error even though the URL is right there in the file. ## Takeaway Same DSL shape, two different jobs: `pluginManagement` = where plugins come from; `dependencyResolutionManagement` = where libraries come from. Keep them straight and your settings file becomes the single, auditable source of truth for all resolution.

  • If you declare mavenCentral() only inside pluginManagement, can your subprojects resolve library dependencies from it?
    No. Plugin and dependency repository lists are independent. You also need mavenCentral() in dependencyResolutionManagement (or a project repositories block) for library resolution.
  • Which block enforces that subprojects can't declare their own repositories?
    dependencyResolutionManagement, via repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS). pluginManagement has no equivalent because plugin repos are already centralized.

saying these in an interview costs you the question

  • Believing the two blocks share one repository list.
  • Expecting a plugin to resolve from a repo declared only in dependencyResolutionManagement.
  • Putting dependencyResolutionManagement before pluginManagement.

context

resolving links…