skip to content

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%

answer

  1. module had a private repositories block
  2. repo not in the central list
  3. central list must be the union of all needed repos
  4. use PREFER_SETTINGS warnings to find them
  5. move the repo up into settings

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.

solid answer

~40 s

The most common cause is that the failing module previously declared its **own** `repositories {}` block pointing at a repository (often an internal Artifactory/Nexus or a special Maven URL) that isn't part of the central `dependencyResolutionManagement` list. Once you enforce `FAIL_ON_PROJECT_REPOS`, project-level repositories are no longer allowed, so that artifact has nowhere to resolve from — you'll see either a hard failure about project repositories or a 'could not find' resolution error after the block is removed. The fix is to move that repository into the central settings-level `repositories {}` block so every module — including this one — can reach it. This is exactly the situation the migration is meant to surface: the central list must be the **union** of all repositories any module needs before you flip on strict mode.

code

bash · 2 lines
bash
# Find every project-level repositories block to reconcile before going strict
grep -rn "repositories {" --include=build.gradle.kts --include=build.gradle .

go deeper

for a junior

Recognize the missing repo had been provided by the module's own block.

for a middle

Diagnose the union-of-repositories gap and fix by moving the repo into the central list.

for a senior

Add the PREFER_SETTINGS pre-flight and mention content filtering to keep the central list lean.

for a principal

Define a process/CI check that reconciles all module repositories into the central list before enforcing strict mode org-wide.

## What's going on Before centralization, a module might have had: ```kotlin // some-module/build.gradle.kts (old) repositories { mavenCentral() maven { url = uri("https://nexus.mycorp.com/internal") } // <-- only here } ``` When you switch the settings file to `FAIL_ON_PROJECT_REPOS`, one of two things happens: 1. If the project block is still present → the build **fails fast** complaining that the project declares repositories. 2. If you removed the project block but **forgot to add `nexus.mycorp.com/internal` to the central list** → resolution fails with 'Could not find <artifact>' because the only repository that had it is gone. ## The fix Make the central list the **union** of everything any module needs: ```kotlin // settings.gradle.kts dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { mavenCentral() google() maven { url = uri("https://nexus.mycorp.com/internal") } // moved up from the module } } ``` ## How to discover the gap before it bites - Use `PREFER_SETTINGS` first: it warns for every module still declaring repos, naming exactly which modules and (by inspection) which URLs you still need to fold into the central list. - Search the codebase for `repositories {` in `build.gradle(.kts)` files and reconcile every URL against the central list. - If a repository is only needed by one module's narrow set of artifacts, you can keep it central but use **repository content filtering** to scope which dependencies resolve from it (that's a related feature, but it lets you centralize without every repo being consulted for every dependency). ## Mental model Strict centralization trades per-module flexibility for one authoritative list. The list must therefore be complete *before* you enforce it; otherwise you've simply removed the only source for some artifacts.

  • How could you have caught this before flipping to strict mode?
    Run PREFER_SETTINGS first — it warns for each module still declaring its own repositories, giving you a checklist of URLs to fold into the central list before enforcing FAIL_ON_PROJECT_REPOS.
  • The central list now has an internal repo that's only relevant to one module. Any concern?
    By default every dependency may be looked up in every central repo, adding lookups. You can scope it with repository content filtering so only the relevant coordinates resolve from that internal repo.

saying these in an interview costs you the question

  • Blaming the dependency version or the cache instead of the missing central repository.
  • Re-adding a project-level repositories block to 'fix' it — that defeats centralization and fails strict mode.
  • Assuming strict mode merges in the old project repos automatically.

context

resolving links…