What is the dependencyResolutionManagement {} block, and which Gradle build file does it belong in?
answer
- settings.gradle(.kts), not build script
- evaluated once, before projects
- holds repositories / repositoriesMode / versionCatalogs
- sibling of pluginManagement
- build-wide, no per-module repetition
basics
~10 sIt is a block in settings.gradle(.kts) — not build.gradle — where you centrally declare repositories and version catalogs for the whole build instead of repeating them in each module.
solid answer
~30 s`dependencyResolutionManagement {}` lives in the **settings script** (`settings.gradle.kts` / `settings.gradle`), which is evaluated once before any project. It is the single, build-wide place to centralize dependency-resolution concerns: a `repositories {}` block shared by every project, a `repositoriesMode` policy, and one or more `versionCatalogs {}`. Because settings is evaluated before projects are configured, declarations here apply to all subprojects without each `build.gradle.kts` repeating them. It pairs conceptually with `pluginManagement {}` (which centralizes *plugin* resolution); `dependencyResolutionManagement` centralizes *regular dependency* resolution. Putting it in a project build script is a mistake — the DSL method only exists on the `Settings` object.
code
kotlin · 11 lines// settings.gradle.kts
dependencyResolutionManagement {
repositories {
mavenCentral()
}
versionCatalogs {
create("libs") {
from(files("gradle/libs.versions.toml"))
}
}
}go deeper
Know it lives in settings.gradle(.kts) and centralizes repositories/version catalogs for the whole build.
Explain the early evaluation order (settings before projects) and that it holds repositories, repositoriesMode, and versionCatalogs.
Contrast it with pluginManagement, explain why a per-project home is impossible, and how it enforces build-wide consistency.
Frame it as the governance hub for dependency sourcing across a large multi-module build and its role in convention/standardization strategy.
## What it is `dependencyResolutionManagement {}` is a DSL block exposed on Gradle's `Settings` object. The **settings script** (`settings.gradle.kts` or `settings.gradle`) is evaluated exactly once, at the very start of a build, *before* any project's `build.gradle.kts` is configured. That ordering is why settings is the right home for *build-wide* policy. ## What lives inside it Three things, all build-scoped: - **`repositories {}`** — a centralized list of repositories (e.g. `mavenCentral()`, `google()`) used to resolve regular dependencies across all projects. - **`repositoriesMode`** — a policy enum controlling whether per-project `repositories {}` blocks are allowed, ignored, or preferred. The notable value is `RepositoriesMode.FAIL_ON_PROJECT_REPOS`. - **`versionCatalogs {}`** — declares one or more version catalogs (commonly backed by `gradle/libs.versions.toml`), producing type-safe accessors like `libs.someLib` in build scripts. ## Why settings, not build A project build script (`build.gradle.kts`) configures a single `Project`. By the time it runs, settings has already finished. The `dependencyResolutionManagement` method simply does not exist on `Project`, so calling it there is a compile/evaluation error. The whole point is *one* declaration that the entire multi-project build inherits. ## Relationship to pluginManagement Think of two sibling settings blocks: `pluginManagement {}` centralizes where **plugins** come from; `dependencyResolutionManagement {}` centralizes where **regular dependencies** come from and how version catalogs are defined. Both appear in the same settings file, conventionally near the top. ```kotlin // settings.gradle.kts pluginManagement { repositories { gradlePluginPortal(); mavenCentral() } } dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() } versionCatalogs { create("libs") { from(files("gradle/libs.versions.toml")) } } } rootProject.name = "my-app" include("app", "core") ``` ## Key takeaway It is a *settings-script structural element*: a single, early-evaluated, build-wide hub for repositories, the repositories-mode policy, and version-catalog declarations.
- What happens if you put dependencyResolutionManagement {} inside a project's build.gradle.kts?It fails — the method exists only on the Settings object, not on Project. Gradle cannot resolve the DSL method there, so the build script errors during configuration.
- How does it relate to pluginManagement {}?Both are settings-script blocks. pluginManagement centralizes plugin resolution; dependencyResolutionManagement centralizes regular dependency resolution and version-catalog declaration. They are siblings in the same settings file.
Like a building's main electrical panel installed before any tenant moves in: wire it once at the entrance (settings) and every apartment (project) draws from it, instead of each unit running its own line to the street.
saying these in an interview costs you the question
- Claiming it goes in build.gradle.kts.
- Confusing it with pluginManagement (which handles plugins, not regular dependencies).
- Thinking it must be repeated per module.