skip to content

Your large multi-module build has repositories {} duplicated in every module's build.gradle.kts. How would you use dependencyResolutionManagement {} to centralize this, and what are the migration risks?

level: seniorimportance: should knowfreq 30%

answer

  1. inventory union of all module repos
  2. declare once in settings repositories {}
  3. interim PREFER_PROJECT/PREFER_SETTINGS
  4. delete per-module blocks incrementally
  5. flip FAIL_ON_PROJECT_REPOS last

basics

~20 s

Move the repository declarations into a single dependencyResolutionManagement { repositories {} } in settings, delete the per-module ones, then set repositoriesMode to FAIL_ON_PROJECT_REPOS to prevent regressions. The risk is modules with unique repos that break when centralized.

solid answer

~50 s

The target state is one `dependencyResolutionManagement { repositories { ... } }` in settings, with every module's local `repositories {}` removed. Migration in steps: (1) inventory every per-module `repositories {}` to find the union of repos actually used; (2) declare that union centrally in settings; (3) start with `repositoriesMode` left at default (`PREFER_PROJECT`) or `PREFER_SETTINGS` so nothing breaks abruptly; (4) delete per-module blocks module by module, verifying resolution; (5) once all are removed, flip to `FAIL_ON_PROJECT_REPOS` to lock the policy and prevent any future module from re-adding repos. Risks: a module that quietly relied on a *unique* repository (an internal mirror, a snapshot repo) will fail to resolve if you forget to include it centrally; ordering/precedence of repos can subtly change which artifact wins for the same coordinates; and `FAIL_ON_PROJECT_REPOS` will hard-break any leftover or newly-added project repo, so flip it only after the cleanup is complete.

code

kotlin · 8 lines
kotlin
// settings.gradle.kts — end state after migration
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) // flip LAST
    repositories {
        mavenCentral()
        maven { url = uri("https://nexus.internal/repository/maven-public/") }
    }
}

go deeper

for a junior

Know the basic move: put repositories in settings, remove from modules.

for a middle

Sequence the migration safely and name repositoriesMode as the enforcement lever.

for a senior

Lay out the incremental rollout, the interim mode choice, and the concrete resolution risks (missing repos, ordering).

for a principal

Frame it as supply-chain governance: single audited source, CI enforcement, and a rollout plan across many teams/repos.

## Goal Collapse N duplicated `repositories {}` blocks into one centralized, governed declaration in `dependencyResolutionManagement {}`, then enforce it so it cannot regress. ## Step-by-step 1. **Inventory.** Search all `build.gradle.kts` for `repositories {`. Build the *union* of every repository referenced — including the easy-to-miss ones: internal Nexus/Artifactory mirrors, snapshot repos, `flatDir`, or a one-off repo a single module needs. 2. **Declare centrally.** Put that union into settings: ```kotlin // settings.gradle.kts dependencyResolutionManagement { repositories { mavenCentral() maven { url = uri("https://nexus.internal/repository/maven-public/") } } } ``` 3. **Choose a safe interim mode.** Leave `repositoriesMode` at the default `PREFER_PROJECT` (or set `PREFER_SETTINGS`) during migration so removing module blocks one at a time stays low-risk. Do **not** start with `FAIL_ON_PROJECT_REPOS` — it would break the build while modules still declare repos. 4. **Delete per-module blocks incrementally.** Remove `repositories {}` from each module, run that module's resolution/tests, confirm green, repeat. 5. **Lock it down.** Once every module is clean, set `repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)`. Now any future `repositories {}` in a build script fails CI, freezing the policy. ## Risks to call out - **Missing a unique repo.** If one module pulled an artifact only its private repo had and you didn't add that repo centrally, resolution fails. The inventory step must be exhaustive. - **Resolution order / artifact shadowing.** The order repositories appear can change which artifact is selected for ambiguous coordinates; centralizing may reorder them. Verify checksums/versions don't shift unexpectedly. - **Premature FAIL_ON_PROJECT_REPOS.** Flipping it before cleanup is done breaks the build; flip last. - **Plugin repos are separate.** `repositories {}` here is for *regular dependencies*; plugin resolution is governed by `pluginManagement {}`. Don't conflate the two during the move. ## Why it is worth it One audited source of truth for where artifacts come from: easier security review, no per-module drift, and `FAIL_ON_PROJECT_REPOS` makes regressions a loud build failure instead of a silent supply-chain risk. ## Scope boundary This question is about using the *block structurally* to centralize and the policy lever (`repositoriesMode`) to enforce — not the deeper mechanics of repository content filtering or central-management internals.

  • Why not enable FAIL_ON_PROJECT_REPOS first, before removing the module-level blocks?
    It immediately fails the build for every module that still declares its own repositories. You enable it only after all per-module blocks are removed, so it locks in the clean state rather than breaking an in-progress migration.
  • What is the single most common way this migration silently breaks resolution?
    Forgetting a unique repository that only one module declared (an internal mirror or snapshot repo). If it is not added to the central list, that module's dependency fails to resolve.
  • Does centralizing dependency repositories also handle plugin repositories?
    No. dependencyResolutionManagement governs regular dependencies; plugin resolution is configured separately in pluginManagement {}. They must be centralized independently.

saying these in an interview costs you the question

  • Flipping FAIL_ON_PROJECT_REPOS before deleting module repos.
  • Assuming all modules use the same repos and skipping the inventory step.
  • Conflating dependency repositories with plugin repositories (pluginManagement).

context

resolving links…