skip to content

How does a Settings plugin use dependencyResolutionManagement to centralize repositories and version catalogs?

level: middleimportance: should knowfreq 45%

answer

  1. DRM = dependencies, not plugins
  2. repositoriesMode FAIL_ON_PROJECT_REPOS
  3. versionCatalogs { create("libs") }
  4. from(files(libs.versions.toml))
  5. central repos for all projects

basics

~10 s

dependencyResolutionManagement in settings declares repositories for all projects and defines version catalogs. A settings plugin calls settings.dependencyResolutionManagement {} to set repositoriesMode, central repositories, and create catalogs like libs once for the whole build.

solid answer

~30 s

`dependencyResolutionManagement {}` is a Settings-level block for centralizing **dependency** (not plugin) resolution across all projects. A `Plugin<Settings>` configures it via `settings.dependencyResolutionManagement { ... }`. Key levers: `repositories {}` declares the shared repositories; `repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)` forbids per-project `repositories {}` so everything resolves centrally; and `versionCatalogs { create("libs") { from(files(...)) } }` (or `library(...)`/`version(...)` calls) defines type-safe catalogs. Packaging this in a settings convention plugin gives every repo identical, governed dependency sources and a shared catalog without copy-pasting into each `settings.gradle.kts`.

code

kotlin · 11 lines
kotlin
settings.dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(settings.layout.rootDirectory.files("gradle/libs.versions.toml"))
        }
    }
}

go deeper

for a junior

Know DRM lives in settings and declares repositories and version catalogs for all projects at once.

for a middle

Explain repositoriesMode options and how versionCatalogs { create("libs") } generates type-safe accessors.

for a senior

Discuss enforcing FAIL_ON_PROJECT_REPOS and sharing a libs.versions.toml via a settings plugin for consistent resolution.

for a principal

Position DRM as the dependency-governance seam: one settings plugin pins repos, bans ad-hoc project repos, and ships a shared catalog org-wide.

## What it does `dependencyResolutionManagement {}` (DRM) is the Settings-phase counterpart to `pluginManagement`, but for **regular dependencies** rather than plugins. It centralizes two things: ### 1. Repositories ```kotlin dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() maven(url = "https://nexus.example.com/repository/maven") } } ``` `repositoriesMode` accepts: - `PREFER_PROJECT` (default) — project `repositories {}` win. - `PREFER_SETTINGS` — settings repositories win, project ones ignored with a warning. - `FAIL_ON_PROJECT_REPOS` — any project declaring its own `repositories {}` fails the build. This is the governance setting: it forces all dependency resolution through the central list. ### 2. Version catalogs ```kotlin dependencyResolutionManagement { versionCatalogs { create("libs") { version("junit", "5.10.0") library("junit", "org.junit.jupiter", "junit-jupiter").versionRef("junit") // or: from(files("../gradle/libs.versions.toml")) } } } ``` This generates the type-safe `libs.junit` accessor available in every build script. ## From a settings plugin A company conventions settings plugin typically does both — pin the internal repository, set `FAIL_ON_PROJECT_REPOS`, and load a shared `libs.versions.toml` via `from(...)` — so every consuming repo gets identical, governed dependency resolution by just applying one plugin. ## DRM vs pluginManagement They are siblings but separate: `pluginManagement.repositories` is for the `plugins {}` DSL; `dependencyResolutionManagement.repositories` is for `dependencies {}`. A repo for one is not automatically a repo for the other.

  • What does RepositoriesMode.FAIL_ON_PROJECT_REPOS achieve?
    It fails the build if any project declares its own repositories {}, forcing all dependency resolution through the central settings list — useful for governance and reproducibility.
  • Is dependencyResolutionManagement.repositories the same as pluginManagement.repositories?
    No. The former resolves regular dependencies (dependencies {}); the latter resolves plugins (plugins {}). They are configured separately.

saying these in an interview costs you the question

  • Saying DRM repositories also resolve plugins — they don't; that's pluginManagement.
  • Forgetting that the default repositoriesMode (PREFER_PROJECT) lets project repos override settings ones.

context

resolving links…