Introduction

This Gradle message means your build has centralized repository management in settings.gradle or settings.gradle.kts, but a module-level build.gradle still tries to add its own repository. Gradle is warning or failing because the project build is violating the repository policy you configured at the settings level.

Why the message appears

Modern Gradle lets you declare dependency repositories centrally with dependencyResolutionManagement. A typical setup looks like this:

1// settings.gradle.kts
2dependencyResolutionManagement {
3    repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS)
4    repositories {
5        google()
6        mavenCentral()
7    }
8}

With this configuration, repositories are supposed to come from settings. If a subproject still contains something like this:

1// app/build.gradle
2repositories {
3    maven { url "https://jitpack.io" }
4}

Gradle reports that the project tried to add maven even though repository preference was already defined centrally.

The goal of this feature is consistency. If every module declares its own repositories, dependency resolution becomes harder to reason about and easier to break.

The clean fix: move repositories into settings

In most projects, the best solution is to remove repositories blocks from module build.gradle files and define everything once in settings.

For example:

1// settings.gradle.kts
2dependencyResolutionManagement {
3    repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS)
4    repositories {
5        google()
6        mavenCentral()
7        maven("https://jitpack.io")
8    }
9}

Then remove the project-level repository block entirely:

1// app/build.gradle
2dependencies {
3    implementation "com.github.User:Repo:1.0.0"
4}

This is the configuration Gradle is trying to steer you toward. It makes repository policy explicit and shared across all modules.

Know the difference between dependency repositories and plugin repositories

A frequent source of confusion is mixing normal dependency repositories with plugin repositories. Plugin resolution belongs in pluginManagement, also in settings, not in a module build.gradle.

For example:

1pluginManagement {
2    repositories {
3        gradlePluginPortal()
4        google()
5        mavenCentral()
6    }
7}

And ordinary library dependencies belong in dependencyResolutionManagement.

If you put plugin repositories in one place and dependency repositories in another by mistake, the error messages can feel inconsistent even though Gradle is behaving correctly.

When you might change the repository mode instead

If you deliberately want individual projects to be allowed to declare repositories, you can change the mode:

1dependencyResolutionManagement {
2    repositoriesMode.set(RepositoriesMode.PREFER_PROJECT)
3    repositories {
4        google()
5        mavenCentral()
6    }
7}

That tells Gradle to let project repositories override or supplement the settings-level repositories. This is occasionally useful during migration, but it is usually not the best long-term structure for a multi-module build.

If your goal is strict enforcement, use:

repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

That turns the policy violation into a hard failure rather than a softer warning-style situation.

Check whether a plugin is adding the repository for you

Sometimes the repository is not written directly in your build.gradle at all. A plugin or applied script can inject it. When that happens, search the build for repositories blocks and applied scripts:

rg "repositories\\s*\\{" .

Also inspect convention plugins, buildSrc, and included builds. If a third-party plugin is forcing a repository, you may need to configure that plugin differently or move the relevant repository to settings so the plugin no longer needs to add it itself.

Common Pitfalls

The biggest mistake is fixing the symptom by duplicating the same repository in both settings and project files. That makes the warning disappear in some setups, but it defeats the whole point of centralized repository management.

Another common issue is confusing pluginManagement with dependencyResolutionManagement. They solve related but different problems.

People also overlook generated or applied build logic. The offending repository may come from a shared Gradle script rather than the visible module file.

Finally, changing to PREFER_PROJECT just to silence the message is usually the wrong fix unless you intentionally want decentralized repository control.

Summary

• The message means a project-level build file added a repository while settings-level repository governance was active.
• The best fix is usually to move all dependency repositories into settings.gradle or settings.gradle.kts.
• Keep plugin repositories in pluginManagement and dependency repositories in dependencyResolutionManagement.
• Use PREFER_PROJECT only when decentralized repository declarations are actually intended.
• Search applied scripts and plugins if the repository is not obviously declared in the module file.