skip to content

What does the publishToMavenLocal task do, and where does it put your artifacts?

level: juniorimportance: must knowfreq 60%

answer

  1. maven-publish plugin
  2. ~/.m2/repository
  3. equivalent of mvn install
  4. writes jar + POM + module metadata
  5. consumed via mavenLocal()

basics

~10 s

publishToMavenLocal installs your built artifacts (jar, POM, metadata) into the local Maven cache at ~/.m2/repository, so other local builds on the same machine can resolve them via mavenLocal().

solid answer

~40 s

The `maven-publish` plugin contributes a `publishToMavenLocal` lifecycle task that writes every declared `MavenPublication` — its main artifact, generated POM, and Gradle Module Metadata — into the user-level Maven repository at `~/.m2/repository` (overridable via `maven.repo.local` or `settings.xml`'s `<localRepository>`). It is the Gradle equivalent of Maven's `mvn install`. The point is fast local iteration: publish library A locally, then a separate project B that declares `repositories { mavenLocal() }` can resolve `A` without a network round-trip or a remote server. It is not for sharing across machines or CI — `~/.m2` is per-developer, untracked, and easily stale. For real distribution you publish to a remote Maven repository instead.

code

bash · 5 lines
bash
# Build and install the library into ~/.m2/repository
./gradlew publishToMavenLocal

# Inspect where it landed (groupId/artifactId/version)
ls ~/.m2/repository/com/example/mylib/1.0.0/

go deeper

for a junior

Know it installs artifacts to ~/.m2/repository, like mvn install, and is consumed via mavenLocal().

for a middle

Name the contributing plugin (maven-publish), what gets written (jar+POM+module metadata), and the local-repo location overrides.

for a senior

Discuss the staleness/shadowing risks and why CI should publish to a real remote instead.

for a principal

Frame the org policy: local publish for dev loops only, with remote repositories and reproducible coordinates as the source of truth.

## What `publishToMavenLocal` is The `maven-publish` plugin defines publications and the tasks that push them out. Two task families exist: - `publish` — pushes all publications to all **remote** `maven { url = ... }` repositories you declared. - `publishToMavenLocal` (often abbreviated `pTML`) — pushes all publications into the **local Maven repository**, the on-disk directory Maven and Gradle both understand at `~/.m2/repository`. It is the Gradle analogue of `mvn install`. ## What actually gets written For each `MavenPublication` it installs, under a `groupId/artifactId/version` path: - the primary artifact(s) — e.g. the `.jar` - the generated **POM** (`.pom`) describing coordinates and dependencies - Gradle **Module Metadata** (`.module`) carrying richer variant/dependency info - any additional artifacts you attached (sources jar, javadoc jar) ## Where it goes Resolution order for the local repo location: 1. the `maven.repo.local` system property if set, 2. `<localRepository>` in `~/.m2/settings.xml`, 3. the default `~/.m2/repository`. ## Consuming what you published A different project resolves it only if it declares the local repo: ```kotlin repositories { mavenLocal() } ``` ## When to use it (and not) Use it for tight local feedback loops — iterating on a library and a consumer side by side on one machine. Do **not** rely on it for CI or sharing between developers: `~/.m2` is per-user, gitignored, and a frequent source of "works on my machine" because a stale local artifact can shadow the intended remote one. For distribution, publish to a real remote repository.

  • How does a consuming project resolve what you published locally?
    It must declare `repositories { mavenLocal() }`; without it, Gradle never looks in `~/.m2`.
  • Why is relying on publishToMavenLocal risky in a team?
    `~/.m2` is per-developer and untracked, so a stale local artifact can shadow the real remote one — classic 'works on my machine' bugs.

It's like saving a draft to your own desktop versus uploading it to a shared drive — handy for you, invisible to everyone else.

saying these in an interview costs you the question

  • Thinking publishToMavenLocal uploads to a shared/remote server.
  • Assuming consumers see it automatically without declaring mavenLocal().

context

resolving links…