skip to content

What is a repository in Gradle, and how do you declare one so your dependencies can be resolved?

level: juniorimportance: must knowfreq 78%

answer

  1. where artifacts + metadata live
  2. repositories {} block
  3. mavenCentral / google / gradlePluginPortal
  4. maven { url = uri(...) }
  5. project repos vs pluginManagement

basics

~10 s

A repository is a source Gradle downloads dependency artifacts and metadata from. You declare them in a repositories {} block, e.g. mavenCentral(), so Gradle knows where to look for the modules you depend on.

solid answer

~40 s

In Gradle, a **repository** is a location (an HTTP server or local directory) where modules — JARs plus their metadata (POM or Gradle Module Metadata) — live. You declare repositories in a `repositories {}` block, usually in `build.gradle.kts`. Common shorthands map to well-known servers: `mavenCentral()`, `google()`, and `gradlePluginPortal()`. For anything else you use `maven { url = uri("https://...") }`. Without at least one repository, Gradle has nowhere to fetch declared dependencies and resolution fails. Repositories only tell Gradle *where* to look; `dependencies {}` declares *what* to fetch. Plugin repositories (for the `plugins {}` block) are declared separately in `pluginManagement {}` inside `settings.gradle.kts`, which is why `gradlePluginPortal()` often appears there rather than in the build script.

code

kotlin · 10 lines
kotlin
// build.gradle.kts
repositories {
    mavenCentral()
    google()
    maven { url = uri("https://repo.spring.io/release") }
}

dependencies {
    implementation("com.google.guava:guava:33.0.0-jre")
}

go deeper

for a junior

Name repositories {}, mavenCentral(), and that it's where dependencies are downloaded from.

for a middle

Distinguish metadata vs artifact, custom maven { url }, and project vs plugin repositories.

for a senior

Discuss how the declared set/order shapes resolution and reproducibility, and when to centralize repos.

for a principal

Frame repository declaration as supply-chain surface area: which sources are trusted org-wide, mirrors, and governance over allowed origins.

## What a repository is Gradle resolves a dependency like `com.google.guava:guava:33.0.0-jre` by contacting one or more **repositories** — servers or directories that host two things: the **artifact** (the JAR/AAR/etc.) and its **metadata** (a `.module` Gradle Module Metadata file, a Maven `.pom`, or an Ivy `ivy.xml`). The metadata is what tells Gradle the module's transitive dependencies, so a repository is far more than a file mirror. ## Declaring them Repositories go in a `repositories {}` block. In a project build script that block configures where *project dependencies* (the `dependencies {}` block) come from: ```kotlin repositories { mavenCentral() // shorthand for https://repo.maven.apache.org/maven2/ google() // Android / Google artifacts maven { url = uri("https://my.company/repo") } // custom Maven repo } ``` ## The well-known shorthands - `mavenCentral()` — Maven Central, the default home of most JVM libraries. - `google()` — Google's Maven repo (Android, Firebase, Guava mirror). - `gradlePluginPortal()` — the Gradle Plugin Portal; the default place plugins resolve from. - `mavenLocal()` — your local `~/.m2/repository` cache; **opt-in only**, see its own pitfalls. ## Custom and non-Maven layouts - `maven { url = uri("...") }` — any Maven-layout HTTP(S) server. - `ivy { url = uri("...") }` — Ivy-layout server, with a customizable `patternLayout`. - `flatDir { dirs("libs") }` — a flat directory of JARs **with no metadata** (last-resort). ## Project repos vs plugin repos Project dependencies resolve from `repositories {}`. The `plugins {}` block resolves from repositories declared in `pluginManagement { repositories { ... } }` in `settings.gradle.kts`, where `gradlePluginPortal()` is the default. Mixing the two up is a common source of "plugin not found" errors. ## Resolution flow When a configuration is resolved, Gradle walks the declared repositories **in order**, asking each for the module's metadata until one answers, then downloads the artifact. So the set and order of repositories directly controls what — and from where — you get.

  • What happens at resolution time if no repositories are declared?
    Gradle fails with an error like "Cannot resolve external dependency ... because no repositories are defined" — there is nowhere to fetch metadata or artifacts from.
  • Where do you declare repositories for plugins applied via the plugins {} block?
    In `pluginManagement { repositories { ... } }` in `settings.gradle.kts`; `gradlePluginPortal()` is the default there, separate from the project's `repositories {}`.

Repositories are the shops Gradle visits; dependencies {} is the shopping list. Without a shop on the list, the cart stays empty no matter what you wrote down.

saying these in an interview costs you the question

  • Claiming a repository stores only JARs and ignoring that metadata (POM/.module) drives transitive resolution.
  • Saying `dependencies {}` and `repositories {}` do the same thing.
  • Thinking the project `repositories {}` block resolves the `plugins {}` block.

context

resolving links…