No. The Gradle migration guide says that, unlike Maven, Gradle has no default repository, so you must declare at least one. To match a Maven build, declare Maven Central explicitly. After a migration, review every declared repository, because the list you end up with decides where your dependencies can come from.
Why this matters after a migration
In a Maven project the repository story is spread across places: the POM, a parent POM, and settings on the build machine. In Gradle it lives in the build scripts. A migration moves that responsibility, and whatever the conversion tool did not carry over is silently missing or silently different.
The guide says the automatic conversion includes the custom repositories specified in the POM. It does not say it converts per machine settings such as mirror configuration, so check those yourself and do not assume they came along.
Steps
- List every repository in the old build: POMs, parent POMs, and the settings file used on build agents and developer machines.
- List every repository in the new build, including plugin repositories.
- For each one ask who runs it and whether you intend to trust it.
- Declare Maven Central explicitly if that is what you want.
- Remove anything you cannot justify.
- Restrict which groups may come from which repository (see below).
repositories {
mavenCentral()
}
The local Maven cache is a repository too
The guide notes that Gradle can resolve dependencies against the local Maven cache, which helps Gradle builds interoperate with Maven builds, but it should not be used unless you need that interoperability. Anything in a developer's local cache then becomes a source, and it differs from machine to machine. See should you use mavenLocal or flatDir in Gradle.
Decision table
| Situation | Suggested approach |
|---|---|
| Only public libraries | Maven Central declared once |
| Private artifacts plus public | Keep private groups on the private repository only |
| Build agents behind a mirror | Declare the mirror in the build, not only on machines |
| Local interop with Maven | Use temporarily, remove after cutover |
For the private plus public case, Gradle supports content filtering so that a private group never resolves from a public repository. That guard blocks dependency confusion, and the details are in Gradle exclusiveContent and can Maven suffer dependency confusion.
A quick audit you can run
Open the build output of a clean build with the cache removed and note the host of every download. Each host should match a repository you declared on purpose. If an unexpected host appears, search the build scripts, init scripts and plugin blocks for it. This takes minutes and turns an assumption about where code comes from into evidence you can show a reviewer.
Plugins need the same care
Build plugins resolve from their own repositories. A migrated build that adds a plugin repository to get one convenience plugin has widened its trust. See where Gradle plugins come from.
Safeguard's dependency scanning and policies can flag components that resolve unexpectedly, and the free scan at gold.safeguard.sh/scan is a quick first look.
Quick check
Do I have to declare a repository in Gradle?
Yes. There is no default, so a build with none cannot download external dependencies.
Does gradle init copy my settings.xml mirrors?
The guide only says it includes repositories specified in the POM. Check mirror and credential settings manually.
Sources
Last reviewed: 19 October 2026.
