What Is the .m2 Folder, and Can You Delete the Maven Local Repository?

If you have ever peeked at your home directory with hidden files visible, you have probably seen a folder called ~/.m2. For Java and Kotlin developers who use Apache Maven or Gradle, this folder is the local repository cache — and it grows silently for years. Whether you want to reclaim disk space or troubleshoot a corrupted dependency, knowing how to safely delete the .m2 folder (or just trim it) is one of those maintenance tasks every Mac developer eventually needs. This guide covers what lives inside, how much space it typically consumes, and the exact steps to clean it without breaking your builds.

What Is the .m2 Folder on a Mac?

The ~/.m2 directory is Maven's local repository. When Maven resolves a dependency — say, org.springframework:spring-core:6.1.0 — it downloads the JAR, POM, and associated metadata from a remote registry (Maven Central by default) and stores a copy at:

• ~/.m2/repository/org/springframework/spring-core/6.1.0/

On subsequent builds, Maven reads that local copy instead of hitting the network. Gradle uses the same directory by convention when the mavenLocal() resolver is configured, though Gradle also maintains its own cache at ~/.gradle/caches.

Two other files commonly live in ~/.m2:

• ~/.m2/settings.xml — your personal Maven configuration (credentials, mirror URLs, proxy settings). This file is small and valuable; you want to keep it.
• ~/.m2/settings-security.xml — encrypted master password used by Maven's password encryption feature.

The repository/ subdirectory is the cache. Everything else is configuration.

How Big Does ~/.m2/repository Get?

The repository folder has no automatic size limit and never prunes itself. On an active Java project, sizes in the 5–20 GB range are common. Multi-module enterprise projects with many transitive dependencies can push past 30 GB over a few years.

To check your actual size right now, open Terminal and run:

• du -sh ~/.m2/repository

Is It Safe to Delete the .m2 Folder?

Yes — with one important caveat about configuration files. The repository cache is completely safe to delete. Maven will re-download every artifact the next time you run a build. The only risk is that the first build after deletion will be slower and requires an internet connection.

What you should not delete without backing up first:

• ~/.m2/settings.xml — if it contains credentials for private registries (Nexus, Artifactory, GitHub Packages), losing it means re-entering those manually.
• ~/.m2/settings-security.xml — if you use Maven's encrypted passwords, delete this and your encrypted credentials become unreadable.

If your ~/.m2 folder contains only the repository/ subdirectory and no hand-edited settings.xml, you can delete the entire directory without hesitation.

How to Delete or Trim the Maven Local Repository on Mac

Choose the approach that matches your goal: full nuke, repository-only, or surgical cleanup.

Option 1: Delete only the repository cache (recommended)

1. Open Terminal.
2. Back up your settings if you have one: cp ~/.m2/settings.xml ~/Desktop/maven-settings-backup.xml
3. Delete just the cache: rm -rf ~/.m2/repository
4. Run your next build normally: mvn install or ./mvnw package. Maven recreates repository/ automatically and re-downloads what it needs.

Option 2: Delete the entire ~/.m2 directory

1. Back up settings first: cp -R ~/.m2 ~/Desktop/m2-backup
2. Delete everything: rm -rf ~/.m2
3. Maven will recreate the directory with default settings on the next invocation.

Option 3: Remove only stale or unused artifacts with Maven's purge plugin

If you want to keep the cache but remove artifacts your current projects no longer reference, Maven's dependency:purge-local-repository goal is the precision tool:

• mvn dependency:purge-local-repository

Run this from within a project directory. Maven resolves your project's current dependency tree and removes any cached versions of those dependencies so they are freshly re-downloaded — useful for fixing corrupted or half-downloaded JARs without touching unrelated artifacts.

Option 4: Remove corrupted or incomplete downloads

A common symptom of a corrupted cache is a build error mentioning a .part file or a lastUpdated file. These marker files tell Maven a previous download failed. You can find and delete them with:

• find ~/.m2/repository -name "*.lastUpdated" -delete
• find ~/.m2/repository -name "*.part" -delete

Snapshot vs. Release Artifacts: What Accumulates Fastest

Maven distinguishes between SNAPSHOT versions (e.g., 1.0-SNAPSHOT) and release versions (e.g., 1.0.0). Snapshots are re-checked against the remote repository on every build (by default, once per day), and old snapshot JARs are not automatically purged from ~/.m2/repository. If your team ships many snapshot builds, the accumulation of timestamped snapshot files is often the single largest contributor to ~/.m2 bloat.

To find the biggest offenders inside the cache:

• du -sh ~/.m2/repository/* | sort -rh | head -20

This shows the top 20 group-level directories by size so you can see which artifact groups consume the most space.

How .m2 Compares to Other Developer Caches on Mac

The ~/.m2 folder is just one of several developer caches that accumulate over time on macOS. Node's node_modules folders and npm cache follow a similar pattern — large, silent, and never self-pruning. Here is a quick comparison of common developer cache locations and their behavior:

• ~/.m2/repository — Maven local repository; safe to delete entirely
• ~/.gradle/caches — Gradle dependency cache; safe to delete; Gradle re-downloads on demand
• ~/.cargo/registry — Rust crate registry; safe to delete; cargo build re-fetches
• ~/.npm — npm's local cache; safe to delete with npm cache clean --force
• ~/Library/Developer/Xcode/DerivedData — Xcode build artifacts; safe to delete; Xcode rebuilds from source
• ~/Library/Caches/CocoaPods — CocoaPods download cache; safe to delete

If you want to audit all of these locations at once and see what is actually safe to remove before touching anything, a tool like Crumb can scan your entire developer cache footprint and surface the largest folders with a single click.

After Deleting: What to Expect on the Next Build

After you remove ~/.m2/repository, the next Maven or Gradle build will download every dependency from scratch. For a large project, this can take several minutes on a fast connection or considerably longer on a slow one. Build output will show many Downloading from central: lines — this is normal.

A few practical tips to make the rebuild smooth:

• Run the clean-up when you have a reliable internet connection, not on a train or airplane Wi-Fi.
• If you use a corporate Nexus or Artifactory mirror, make sure your settings.xml is in place before the first build — otherwise Maven will try Maven Central directly and may fail to find internal artifacts.
• For CI/CD pipelines, the ~/.m2/repository is usually stored as a cache layer. After deleting locally, your local rebuild is independent of the pipeline cache.

Managing developer caches is a routine part of keeping your Mac's disk space under control. The Maven local repository is one of the more forgiving caches to clear — everything it contains was downloaded once and can be downloaded again.