skip to content

Centralized Repository Management

4 roadmaps5 questions

Declaring repositories once in settings via dependencyResolutionManagement and enforcing it with FAIL_ON_PROJECT_REPOS. Asked because it is the modern way to stop every subproject inventing its own repository list.

on this pageshow

explore

questions

5

What is centralized repository management in Gradle, and where do you configure it?

level: juniorimportance: must knowfreq 55%

answer

  1. settings.gradle.kts not build.gradle.kts
  2. dependencyResolutionManagement { repositories {} }
  3. added in Gradle 6.8
  4. one place for the whole build
  5. separate from pluginManagement.repositories

basics

~10 s

It's declaring repositories once for the whole build inside settings.gradle.kts using dependencyResolutionManagement { repositories {} }, instead of repeating repositories {} in every project's build.gradle.kts.

solid answer

~40 s

Centralized repository management lets you declare all dependency repositories in one place — the `dependencyResolutionManagement { repositories { } }` block in `settings.gradle.kts` — so every subproject resolves dependencies from the same set without each `build.gradle.kts` repeating its own `repositories {}` block. It was introduced in Gradle 6.8. The settings file is evaluated once, before any project is configured, so it's the natural home for build-wide concerns. This removes duplication, guarantees consistency across modules, and gives you a single audit point for which repositories the build is allowed to use. You can pair it with a `repositoriesMode` to actively forbid project-level repositories, turning the central list into the single source of truth.

code

kotlin · 8 lines
kotlin
// settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        mavenCentral()
        google()
        maven { url = uri("https://repo.mycorp.com/releases") }
    }
}

go deeper

for a junior

Know it lives in settings.gradle.kts under dependencyResolutionManagement { repositories {} } and removes per-module duplication.

for a middle

Explain the init-phase rationale and that it's distinct from pluginManagement and buildscript repositories.

for a senior

Tie it to governance/auditability and mention repositoriesMode for enforcement.

for a principal

Frame it as org-wide dependency policy: a single audited repository surface enforced across all teams' builds.

## The problem it solves In a multi-module Gradle build, dependencies are downloaded from **repositories** (Maven Central, Google's Maven repo, internal Artifactory/Nexus, etc.). Traditionally each module declared its own `repositories { }` block inside its `build.gradle.kts`. In a 30-module build that meant the same `mavenCentral()` line copy-pasted 30 times — easy to drift, hard to audit, and a security hole because any module could quietly add a new repository. ## The mechanism Gradle's `settings.gradle.kts` is evaluated **once**, before any project is configured, during the *initialization* phase. Because of that, it's the right place for build-wide policy. Gradle 6.8 added a settings-level block: ```kotlin // settings.gradle.kts dependencyResolutionManagement { repositories { mavenCentral() google() } } ``` Once declared here, **every** subproject resolves its production dependencies from this set; no `repositories {}` is needed in any `build.gradle.kts`. ## Key distinctions - `dependencyResolutionManagement.repositories` controls repositories for **regular (production) dependencies**. - It is *separate* from `pluginManagement.repositories`, which controls where **plugins** are fetched. - `buildscript { repositories {} }` (legacy plugin/classpath resolution) is also separate. ## Enforcement The block also exposes `repositoriesMode`, a `Property<RepositoriesMode>`. Setting it to `RepositoriesMode.FAIL_ON_PROJECT_REPOS` makes the build **fail** if any project also declares its own repositories — making the central list authoritative. The default is `PREFER_PROJECT` (project repos win and the central ones are ignored for that project). ## Why teams adopt it - **Consistency**: every module sees the same repositories, so resolution is reproducible. - **Governance/security**: one audited list; no rogue repo slipping in. - **Maintenance**: change a URL or add an internal mirror in one file.

  • Does this block also control where plugins are downloaded from?
    No. Plugin repositories are configured in pluginManagement { repositories {} }, a separate settings block. dependencyResolutionManagement only governs regular project dependencies.
  • Since which Gradle version is it available?
    Gradle 6.8 introduced dependencyResolutionManagement and the repositoriesMode property.

saying these in an interview costs you the question

  • Claiming the block goes in the root build.gradle.kts — it belongs in settings.gradle.kts.
  • Confusing it with pluginManagement.repositories, which is for plugins.

context

resolving links…

open as a page

What does RepositoriesMode.FAIL_ON_PROJECT_REPOS do, and why would you set it?

level: middleimportance: must knowfreq 50%

basics

~10 s

It makes the build fail if any subproject declares its own repositories {} block, forcing all repositories to come from the central settings.gradle.kts list — making that list the single source of truth.

open as a page

After switching to FAIL_ON_PROJECT_REPOS, a previously-working module fails resolution for a dependency it used to download fine. What likely happened and how do you fix it?

level: middleimportance: should knowfreq 30%

basics

~20 s

That module had its own repositories {} block providing a repo not in the central list. Strict mode disables/forbids project repos, so the dependency can't be found. Fix: add that repository to the central dependencyResolutionManagement block.

open as a page

Compare PREFER_PROJECT, PREFER_SETTINGS, and FAIL_ON_PROJECT_REPOS. When would you choose each during a migration?

level: seniorimportance: should knowfreq 35%

basics

~10 s

PREFER_PROJECT (default) lets project repos override central; PREFER_SETTINGS uses central and ignores project repos; FAIL_ON_PROJECT_REPOS fails if any project declares repos. Use PREFER_SETTINGS mid-migration, then FAIL_ON_PROJECT_REPOS once clean.

open as a page

A team centralizes dependency repositories with FAIL_ON_PROJECT_REPOS, but their convention plugin still needs a special repository for plugins. Where does that go, and why doesn't the strict mode affect it?

level: seniorimportance: should knowfreq 25%

basics

~10 s

Plugin repositories go in pluginManagement { repositories {} } in settings.gradle.kts. dependencyResolutionManagement and its repositoriesMode only govern regular dependency repositories, so FAIL_ON_PROJECT_REPOS doesn't touch plugin resolution.

open as a page