Maven's local repository is one of the older ideas in this space — it predates npm, Cargo, and most of the tools that copied its basic design — and it has one specific behaviour that catches out developers who haven't hit it before: SNAPSHOT dependencies. Unlike a normal release version, which Maven downloads once and reuses forever, a SNAPSHOT version is designed to change, and Maven's local cache handles that by keeping old copies around rather than overwriting them cleanly.

Where the repository lives

Maven stores every downloaded dependency at ~/.m2/repository, organised into a directory structure mirroring each artefact's Maven coordinates — group ID, artifact ID, and version each become a nested folder. A dependency like org.apache.commons:commons-lang3:3.14.0 lives at ~/.m2/repository/org/apache/commons/commons-lang3/3.14.0/.

du -sh ~/.m2/repository

For anyone who has worked on Java or JVM-based projects (including Android projects using Maven-style coordinates even under Gradle) for a few years, this commonly reaches several gigabytes, sometimes considerably more if large frameworks with heavy transitive dependency trees (a full Spring or Hadoop stack, for instance) are involved.

Why release versions are safe to accumulate

For a normal, immutable release version — anything not ending in -SNAPSHOT — Maven's assumption (correctly, by convention) is that once published, that exact version's content never changes. commons-lang3:3.14.0 today is bit-for-bit identical to commons-lang3:3.14.0 a year from now. This is why Maven is comfortable caching release versions indefinitely without ever re-checking them — there's nothing to re-check.

The practical result is that release-version accumulation in ~/.m2/repository is not really a problem the way a growing cache elsewhere might be — every entry is a version you genuinely used at some point, deduplicated by exact version already. The real growth driver is breadth: how many different projects, each with their own dependency trees, have you built on this machine.

Why SNAPSHOT versions are different, and why they pile up

A -SNAPSHOT version (like myapp-core:1.5.0-SNAPSHOT) is, by Maven convention, a version still under active development — the artefact behind that exact version string is expected to change over time as new builds are published. To support this, Maven's local repository stores snapshot artefacts with timestamped internal filenames even though the folder is named after the base snapshot version, and by default it will periodically re-check a remote repository for a newer snapshot build rather than trusting what's cached forever.

Over the life of a project with active SNAPSHOT dependencies — common in a multi-module build where one module depends on another module's in-development snapshot — the local repository can accumulate many historical snapshot builds for what looks like the same single version string, since Maven doesn't always clean up a superseded snapshot artefact automatically.

mvn dependency:purge-local-repository

This is the built-in Maven command purpose-built for the cleanup this article is about:

mvn dependency:purge-local-repository

Run from inside a project, this removes that project's dependencies from the local repository and re-resolves them fresh — useful specifically when you suspect a corrupted or stale artefact (a common symptom: a build failing with a checksum mismatch, or a SNAPSHOT dependency that stubbornly won't pick up a change you know was published) rather than trusting the existing cached copy.

It accepts a -DreResolve=false flag if you want to purge without immediately re-downloading, useful if you're clearing space and don't need the project built again right away.

There's also a narrower, manual approach for snapshot-specific cleanup: deleting a specific artefact's folder by hand forces Maven to re-fetch it on the next build that needs it, without affecting anything else in the repository.

rm -rf ~/.m2/repository/com/mycompany/myapp-core/1.5.0-SNAPSHOT

Deleting the whole repository

For a general disk-space reclaim rather than fixing a specific dependency issue, the entire repository is safe to delete:

rm -rf ~/.m2/repository

Maven re-downloads every dependency needed on the next build across every project. This is the equivalent of npm's cache clean --force or Cargo's registry deletion — total, but entirely recoverable through normal build activity, at the cost of time rather than correctness.

A note on corporate and private repositories

If your ~/.m2/settings.xml points at an internal artifact repository (Nexus, Artifactory, or similar) rather than only Maven Central, be aware that deleting your local cache means your next build re-downloads everything from that internal server, which may be slower than Maven Central depending on your network setup, or may briefly increase load on a shared internal repository if many developers clear their caches around the same time (during a company-wide tooling migration, for instance). Not a reason to avoid cleaning up, just a reason to pick a low-traffic moment if you're on a small, shared internal repository.

IDE-managed Maven imports add their own indexing on top

If you use IntelliJ IDEA or Eclipse to work with Maven projects, be aware that the IDE performs its own indexing of ~/.m2/repository to power features like dependency search and auto-import, and that index is stored separately under the IDE's own cache location rather than inside .m2 itself. Deleting or purging the Maven repository without also letting the IDE re-sync (usually an automatic Reload Maven Project action, or a manual trigger if it doesn't happen on its own) can leave the IDE briefly out of sync with what's actually on disk — showing dependencies as resolved when they've just been deleted, until the next sync catches up. This isn't dangerous, just worth expecting rather than assuming something's broken if IDE and filesystem briefly disagree right after a cleanup.

Multi-module builds concentrate the SNAPSHOT problem

The SNAPSHOT accumulation problem described above tends to be worse specifically in multi-module Maven builds, where one module's SNAPSHOT artefact is a direct dependency of another module in the same larger project. Because each module might get rebuilt and reinstalled to the local repository frequently during active development (mvn install running many times a day as changes are tested across modules), the historical buildup of superseded snapshot artefacts for actively developed multi-module projects can noticeably outpace what a simpler, single-module project would ever produce.

A practical routine

  1. du -sh ~/.m2/repository to see the current size.
  2. If you're chasing a specific build problem involving a SNAPSHOT dependency, delete just that artefact's version folder, or run mvn dependency:purge-local-repository scoped to the affected project.
  3. For general disk pressure with no build issues, deleting the entire repository is safe and reclaims the most space in one step.
  4. If you work with SNAPSHOT dependencies regularly, periodically purging old snapshot builds for modules you no longer actively track keeps the repository from silently accumulating superseded artefacts indefinitely.

Where VolumeLens fits in

~/.m2/repository is one of the more predictable large folders on a Java developer's Mac, but its nested-by-coordinate structure makes it tedious to inspect by hand for what's actually taking the space. VolumeLens draws it out as nested rectangles sized to scale, so the largest dependency trees are visible immediately rather than requiring you to walk group-ID folders one at a time. See the free scan for yourself.