Gradle and Maven caches on Mac: sizes and what's safe to clear

If you're checking your Gradle cache size on a Mac, look in ~/.gradle/caches, a hidden folder in your home folder. It holds every dependency your Java, Kotlin and Android builds have downloaded, plus results Gradle can reuse, shared by all your projects. Maven keeps its own equivalent in ~/.m2/repository.

Both are caches in the useful sense: delete them and your next build downloads what it needs again. Gradle's cache is Safe to clear. Maven's repository is Usually safe, because it can also hold libraries you built and installed yourself.

Gradle also trims its cache by itself, removing what it hasn't used for 7 to 30 days, but only while Gradle is running builds. Maven doesn't trim its repository at all. So a large Gradle cache usually reflects last month's projects, while a large Maven repository can reflect years.

This post goes through both tools on a Mac: what each folder holds, how Gradle's cleanup works, what's safe to clear and what to keep. If you build Android apps, the post on Android Studio taking too much space covers the SDK, emulators and Android Studio's own folders.

Where Gradle and Maven keep their files on a Mac

Each tool has one folder in your home folder, shared by every project, plus build folders inside each project. Settings live right next to the caches, which is why neither home folder should go to the Trash as a whole.

What's in .gradle and .m2?

Item	What it holds	Level
~/.gradle/caches	Downloaded dependencies, the local build cache, generated files	Safe
~/.gradle/wrapper/dists	Copies of Gradle, one per version your projects use	Safe
~/.gradle/jdks	Java versions Gradle downloaded for builds that asked for one	Check first
~/.gradle/gradle.properties and init.d	Your Gradle settings and startup scripts	Keep
~/.m2/repository	Downloaded libraries and plugins, and artifacts you installed	Usually safe
~/.m2/wrapper/dists	Copies of Maven, one per version your projects use	Safe
~/.m2/settings.xml	Your Maven settings: mirrors, proxies, server logins	Keep

Gradle's documentation calls ~/.gradle the Gradle User Home. The daemon folder there holds the registry and logs of Gradle's background process; Gradle deletes logs older than 14 days.

Why can't you see them in Finder?

Folders whose names start with a period are hidden. To open one, choose Go › Go to Folder in Finder, type ~/.gradle or ~/.m2 and press Return. To see them in your home folder, press Shift-Command-Period; press it again to hide them.

To see a folder's size, select it and choose File › Get Info. A large cache holds a great many small files, so the size can take a while to appear.

Where do they show up in Storage settings?

Not by name. System Settings › General › Storage has no category for developer tools, so hidden folders such as ~/.gradle usually land in System Data, which Apple describes as files that don't fit the other categories. The System Data guide explains what else ends up there.

Build folders inside your projects are a different case: they sit among your documents and are usually counted under Documents. The steps here are the same in macOS 26 Tahoe and macOS 27.

Could your caches be somewhere else?

Yes, if someone moved them. Gradle uses another folder when the GRADLE_USER_HOME setting is defined, and IntelliJ IDEA shows the one it uses in Settings › Build, Execution, Deployment › Build Tools › Gradle, in the Gradle user home field.

Maven reads its repository's location from settings.xml. In IntelliJ IDEA, the Local repository field in the Maven settings shows the folder in use, and an Override option changes it.

Can you keep the caches on an external drive?

Yes, if the drive is always connected when you build. Gradle stores everything in the folder GRADLE_USER_HOME names, and IntelliJ IDEA's Gradle user home field sets it for builds the IDE runs. JetBrains notes that a value typed in that field takes precedence, and that you may need to restart the IDE for a change to take effect.

Maven's repository moves the same way, with the localRepository setting in ~/.m2/settings.xml or IntelliJ IDEA's Override option for Local repository. Gradle documents that it finds Maven's repository through the same file.

A few cautions apply. Builds fail or download everything again whenever the drive is missing, and a slow drive makes every build slower, since builds read and write these folders constantly. Gradle's settings move with its home folder, so copy gradle.properties and init.d across. Maven's settings.xml stays in ~/.m2.

For most Macs, clearing the caches now and then is simpler than moving them. Moving them suits a Mac with a small internal disk that builds every day.

How big the Gradle cache gets on a Mac, and why

Which folders in caches take the most space?

Gradle's documentation describes the folders inside ~/.gradle/caches. The number at the end of a name is the format version of that cache, not a Gradle version.

Folder	What it holds
modules-2	Downloaded dependencies: libraries, their metadata and POM files
transforms-3 and later	Results of artifact transforms, such as processed Android libraries
build-cache-1	The local build cache: task outputs Gradle can reuse
jars-9	JARs Gradle instruments for its own use
A folder per Gradle version	Generated JARs and compiled build scripts for that version

Which one is largest depends on your projects. To see for yourself, open ~/.gradle/caches in Finder, choose View › as List, then View › Show View Options, and select Calculate all sizes.

Why are there two transforms folders?

Because Gradle changed the cache's format between versions. Gradle's documentation explains that when two format versions sit side by side, such as transforms-3 and transforms-4, the older one was left by an earlier Gradle version. Only the current format is written, and the old one is cleaned up after it has gone unused long enough.

The same goes for folders named after Gradle versions, such as 9.8.1 or 8.14.3. Each holds files for that version only, so a Mac that builds projects on several Gradle versions keeps a set for each.

How much space is normal?

There's no normal size. It depends on how many projects you build, how many dependencies they have and how many Gradle versions they use. The research behind the app's catalog puts Java and Android developer data together, with Gradle's caches, Maven's repository and Android's SDK images, at about 10 to 100 GB on a working Mac.

A Mac that builds one small library stays well below that. A Mac that builds several Android apps on different Gradle versions can be near the top.

How Gradle cleans its own caches

What does Gradle delete by itself?

Gradle tracks when it last used each file in its caches and removes what's gone unused. Its documentation lists six kinds of cached data, each with its own retention period.

• Released Gradle versions30 days · Safe
• Downloaded dependencies30 days · Safe
• Daemon logs14 days · Safe
• Snapshot Gradle versions7 days · Safe
• Files Gradle created7 days · Safe
• Local build cache entries7 days · Safe

Gradle's default retention periods, from its documentation on Gradle-managed directories. Gradle 8.0 and later can be set to other periods; older versions use 7 or 30 days.

Downloaded files are kept longer because getting them back costs a download. Files Gradle made itself, such as transforms, go after a week because Gradle can make them again from what's already on your Mac.

Gradle distributions in ~/.gradle/wrapper/dists follow their caches: once a version's own cache folder is gone, its distribution is removed too.

When does the cleanup run?

At most once every 24 hours, in the background, when Gradle's background process, the daemon, stops. The daemon stops by itself after 3 hours without a build, or when the Mac is low on memory. If a build runs without the daemon, the cleanup runs in the foreground when the build ends.

Each project's own .gradle folder is checked the same way: build state for Gradle versions the project hasn't used for 7 days is deleted.

Why is the cache still big if Gradle cleans it?

Because the cleanup only removes what's gone unused. Everything your projects used in the last week or month stays, and that can be a lot. Several projects with large, different dependencies keep all of them.

There's a second reason that's easy to miss: the cleanup only runs when Gradle runs. If you stopped doing Android or Java work, no daemon starts, so nothing ever cleans the caches you left. They stay exactly as they were on the day of your last build.

What doesn't Gradle clean up?

• Downloaded JDKs in ~/.gradle/jdks. Gradle's documentation says it never updates them, and the cleanup doesn't cover them.
• Build folders inside your projects. Only a clean task or you removes them.
• Your settings: gradle.properties and the scripts in init.d.
• Maven's repository, even when a Gradle build reads from it.

Can you make Gradle keep less?

Yes, but only with a script. Gradle 8.0 and later read retention periods from an initialization script in ~/.gradle/init.d, and the same script can switch cleanup off or make it run after every build. Its documentation includes examples.

There's no setting for it in Android Studio or IntelliJ IDEA. For most people the defaults are fine, and clearing the cache once, when you need the space, is simpler than tuning it.

Is it safe to clear the Gradle cache?

What happens after you delete ~/.gradle/caches?

Nothing breaks. The Gradle caches entry rates it Safe: Gradle downloads or regenerates anything missing on the next build. Your projects and their source code aren't in it.

What you pay is time. The next build of each project downloads its dependencies again and redoes work the build cache would have skipped. Builds in offline mode fail until the dependencies are back, and a build that's running while you remove the folder may fail.

How do you clear it in Finder?

1. Quit Android Studio, IntelliJ IDEA and any other app that builds with Gradle, and let running builds finish.
2. In Finder, choose Go › Go to Folder, type ~/.gradle and press Return.
3. Move the caches folder to the Trash. Leave everything else in ~/.gradle.
4. Build one project to check it works, then empty the Trash.

The Trash holds the folder until you empty it, so the space only comes back then. With this many small files, emptying it can take a while.

What if you need to build offline afterwards?

Clear caches on a good connection, not before a flight. Gradle's offline mode builds only from what's already cached, and Maven's offline mode works the same way. IntelliJ IDEA has an offline switch in the Gradle tool window and a Work offline checkbox in its Maven settings.

With an empty cache, an offline build has nothing to use and fails. Build each project you'll need once while you're online, and the cache is ready again.

Should you delete only part of it?

You can. Every folder in the caches comes back by itself, so removing a part is as safe as removing all of it. Two parts are worth removing on their own:

• Folders for Gradle versions you no longer use, such as an old 8.x folder when your projects have moved to Gradle 9.
• An older format folder next to a newer one, such as transforms-3 when transforms-4 exists.

Gradle would remove both by itself once they'd gone unused long enough, but only if it runs. Removing modules-2 or build-cache-1 instead frees the most space now, at the cost of the downloads and rebuilds above.

Does refreshing dependencies free space?

No. Gradle's option to refresh dependencies makes it check its repositories again for dynamic and changing versions. Its documentation calls it a common misconception that this forces everything to download again: it does only what's needed, and frees nothing.

Android Studio's and IntelliJ IDEA's File › Invalidate Caches is about the IDE's own indexes, not Gradle's caches. It doesn't touch ~/.gradle.

Which parts of .gradle should stay?

• gradle.properties, your global Gradle settings. It can hold settings your builds read, including credentials for private repositories, which may not be stored anywhere else.
• The init.d folder, with any startup scripts, including your cleanup settings.
• JDKs in jdks that your projects still use. Removing one only means a download, but check first.

If Android was your only use for Gradle, the post on removing Android Studio completely covers when the whole .gradle folder can go.

Gradle versions and downloaded JDKs

Which Gradle versions do your projects use?

Projects built with the Gradle Wrapper name their version in gradle/wrapper/gradle-wrapper.properties, in the distributionUrl line. The wrapper downloads that version into ~/.gradle/wrapper/dists the first time the project builds, in a folder named after the version.

A name ending in -bin is Gradle alone. A name ending in -all adds Gradle's source code and documentation, which IDEs can use. For Gradle 9.8.1, the -bin download is about 145 MB and the -all download about 252 MB, before they're unpacked.

How do you find every project's Gradle version?

Finder's search can list them, because the wrapper's settings file has the same name in every project and sits in an ordinary folder.

1. Open a Finder window and go to the folder that holds your projects.
2. Type gradle-wrapper.properties in the search field and press Return.
3. Next to Search:, click your projects folder's name instead of This Mac.
4. Select each result and press the Space bar. Quick Look shows the file, and its distributionUrl line ends with the version, such as gradle-8.14.3-bin.zip.

On the Mac measured for this post, the search found three such files but only one project. The other two belonged to libraries inside the project's node_modules folder, as React Native libraries ship with wrapper files of their own. Only the app's own file, in its android folder, decides which Gradle version a build downloads.

Compare what you find with the folders in ~/.gradle/wrapper/dists. A version no project names is one Gradle will drop after 30 days of not being used, or that you can move to the Trash now.

Is it safe to delete wrapper/dists?

Yes. Gradle Wrapper distributions are Safe: the wrapper downloads a version again when a project needs it, which takes time and a network connection. Versions no project has used for 30 days are removed by Gradle anyway.

If you see both the -bin and -all download of the same version, two projects ask for different ones. Switching them to the same kind keeps one copy instead of two.

Why do JDKs pile up in .gradle/jdks?

When a build asks for a Java version through Gradle's toolchain support and Gradle can't find one installed, it downloads one into ~/.gradle/jdks. Gradle's documentation says these JDKs are never updated, even when a newer minor version exists, so each new requirement adds one and old ones stay.

To remove one, Gradle's documentation says to delete its folder from jdks. Quit your IDE first: Gradle's daemon remembers where each JDK is until it restarts. Java versions installed in /Library/Java/JavaVirtualMachines are separate and aren't affected.

What about Gradle installed with Homebrew or SDKMAN?

Most projects use the wrapper, so a separately installed Gradle often goes unused. If you installed Gradle or Maven with Homebrew, Homebrew removes old versions with its own cleanup; the post on Homebrew disk space explains it.

SDKMAN keeps every Gradle, Maven and Java version you install with it in ~/.sdkman/candidates. The SDKMAN candidates entry rates it Review first: SDKMAN uninstalls versions one at a time, and you should keep the ones set as your defaults.

Maven's local repository: the .m2 folder

What's in ~/.m2/repository?

Maven's documentation describes the local repository as a folder that caches remote downloads and holds temporary build artifacts you haven't released yet. Every Maven project on your Mac shares it.

Inside, folders follow each library's group ID, with dots becoming folders. A library from the group org.apache.maven sits in ~/.m2/repository/org/apache/maven, with a folder for each library and one for each version.

Is it safe to delete the .m2 folder?

Not the whole folder: ~/.m2 also holds settings.xml, where Maven keeps mirrors, proxies and logins for your company's servers. Remove only the repository folder inside it.

The repository itself is Usually safe. Maven's documentation says you shouldn't need to touch it, except to clean it out when you're short on disk space, or erase it completely if you're willing to download everything again. Maven downloads anything missing on the next build.

The catch is artifacts you installed yourself. When you build a project and install it locally, other projects on your Mac can use it before it's released. Those come back only when you build and install that project again. The Maven local repository entry explains both.

How do you find artifacts you installed yourself?

By their group ID. Your own projects usually use your company's or your own domain, so their artifacts are in a folder such as ~/.m2/repository/com/example. Look there before you remove the repository, and note which projects you'd have to build and install again.

Maven can also keep installed artifacts apart from downloaded ones, with a feature of its resolver called the split local repository. It's off by default, and turning it on is a configuration change rather than a setting in an app.

Does Maven clean up after itself?

No. Maven's documentation describes no automatic cleanup of the local repository, so every version of every library any project has used stays. A repository on a Mac that has built Java projects for years can hold every version along the way.

Maven's dependency plugin has a goal that removes a project's dependencies from the repository, and by default downloads them again. It's useful for fixing a damaged download rather than freeing space, and it runs from Terminal or your IDE.

How do you clear Maven's repository in Finder?

1. Quit your IDE and let running builds finish.
2. In Finder, choose Go › Go to Folder, type ~/.m2 and press Return.
3. Check the folders of artifacts you installed yourself, as above.
4. Move the repository folder to the Trash. Leave settings.xml and any other files.
5. Build your projects, installing your own libraries first, then empty the Trash.

To clear less, open the repository and remove only the group folders of libraries you no longer use. Maven downloads anything a project still needs.

Does Gradle use .m2 too?

Sometimes. A Gradle build that lists the local Maven repository among its repositories reads artifacts from ~/.m2/repository, and Gradle's documentation adds that it may reuse downloads from there even without that. Gradle's documentation advises against relying on it, calling it a cache rather than a true repository.

So clearing ~/.m2 can make a Gradle build download a few more files, but it doesn't break it, unless the build needs artifacts you installed there yourself.

What is ~/.m2/wrapper?

Projects with the Maven Wrapper name the Maven version they need, and the wrapper downloads it into ~/.m2/wrapper/dists. Maven Wrapper distributions are Safe: Maven itself is small, about 10 MB to download for Maven 3.10.0, and the wrapper downloads it again when a project needs it. Unlike Gradle's, versions no project uses stay until you remove them.

Build folders inside your projects

Is it safe to delete build and target folders?

Mostly. Gradle writes everything a build produces, compiled code, APKs, JAR files and test reports, into a build folder next to each module's build script. Maven writes its output into a target folder next to pom.xml. Both are Safe and come back on the next build.

The exception is a release you shipped. A build folder can hold the app you published and the mapping files you need to read crash reports from it. Copy those somewhere safe before you remove the folder.

How do you clean them from your IDE?

You don't need Terminal for this. Each IDE runs the build tool's own clean step:

• Android Studio: choose Build › Clean Project. Android's documentation says it deletes all intermediate and cached build files.
• IntelliJ IDEA, Gradle projects: in the Gradle tool window, open the project's tasks, Control-click clean and choose Run.
• IntelliJ IDEA, Maven projects: in the Maven tool window, open Lifecycle, Control-click clean and choose Run.

A clean only affects the project you have open. For projects you no longer open, move their build or target folders to the Trash in Finder.

What is the hidden .gradle folder in a project?

Gradle keeps project-specific caches at the root of each project, in a hidden .gradle folder: build state from the last build for each Gradle version, and the configuration cache, which lets later builds skip a step. It's Safe and separate from the one in your home folder.

Which other JVM tools keep caches?

Tool	Folder	Level
Kotlin/Native	~/.konan	Safe; downloaded on the next native build
Apache Ivy and older sbt	~/.ivy2/cache	Safe; downloaded on the next build
sbt	target in each Scala project	Safe; rebuilt on the next build
Coursier	~/Library/Caches/Coursier/arc	Review; installed Java versions
JetBrains IDEs	~/Library/Caches/JetBrains	Usually safe; indexes and Local History

Coursier's folder is the trap here. It sits inside the Library's Caches folder but holds installed Java versions, and your shell or editor may be set to use one of them.

What's safe to clear: Gradle and Maven compared

What does removing each part cost?

Part	Level	What removing it costs	How it comes back
~/.gradle/caches	Safe	Downloads and a slower first build	By itself, on the next build
~/.gradle/wrapper/dists	Safe	A download per Gradle version	By itself, when a project builds
~/.gradle/jdks	Check first	A Java download per project that needs it	By itself, if downloads are allowed
~/.m2/repository	Usually safe	Downloads, and your installed artifacts	Downloads by itself; yours you install again
Project build and target	Safe	A full build; shipped releases inside	By itself, on the next build
gradle.properties, settings.xml	Keep	Settings and logins	Only from a backup

In what order should you clean up?

1. Measure. Check ~/.gradle/caches, ~/.m2/repository and your projects folder with Get Info.
2. Quit your IDEs and let builds finish.
3. Remove build folders of projects you've finished, after copying any release you shipped.
4. Remove old pieces of the Gradle cache: folders for Gradle versions you no longer use and older format folders.
5. Remove the whole Gradle cache if you still need space, or if you've stopped Gradle work.
6. Check your own artifacts in ~/.m2/repository, then remove the repository or the groups you no longer use.
7. Build one project per tool, then empty the Trash.

What should you never delete?

• The whole ~/.gradle or ~/.m2 folder. Your settings, scripts and logins are inside.
• Caches while a build is running. Quit the IDE first.
• The gradle folder inside a project. It holds the wrapper's settings and is part of your project's code.
• Release builds and their mapping files, unless you've kept a copy.
• Anything a web page tells you to paste into Terminal. Commands that delete files can't be undone, and fake cleanup guides are a known way to install malware.

Will clearing the Gradle cache make builds faster?

No, the opposite. The cache exists to make builds faster, so the first build of each project afterwards is slower while Gradle downloads and rebuilds. Your Mac doesn't get faster either. Clearing it frees space, and that's all.

How do you keep the caches from filling the disk again?

• Let Gradle's cleanup do its work: on a Mac you build on regularly, the cache settles at what the last month needed.
• When you stop Java or Android work for a while, clear the Gradle cache once, since its cleanup won't run.
• Look through ~/.m2/repository once a year, since Maven never trims it.
• Remove build and target folders when you put a project away.
• Keep projects on the same Gradle version where you can, so one distribution and one set of caches serve them all.
• Exclude the caches from Time Machine in System Settings › General › Time Machine, by clicking Options.

Gradle marks its caches with a CACHEDIR.TAG file so backup tools that follow that convention can skip them. Apple doesn't document Time Machine reading these files, so add the folders to Time Machine's exclusions yourself.

How the app does it

Wombit explains these folders like everything else on the disk. Select one in the map or the list, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.

Cleanup lists them by level:

• Gradle's caches, Gradle versions in wrapper/dists, daemon logs, project build and .gradle folders, Maven's target folders, Maven Wrapper versions and Kotlin/Native's folder are Safe. They count toward the safe total and start checked.
• Maven's local repository is Usually safe and waits for you to check it.
• SDKMAN's and Coursier's Java versions are Review first, explained with each tool's own way to remove them.

Everything the app removes here goes to the Trash, where you can put it back until you empty it.

• ~/.gradle/caches

  Gradle caches

  Dependencies, build cache entries and other files that Gradle keeps for all the Java, Kotlin and Android projects you build.

  Safe · Moves it to the Trash

• ~/.gradle/wrapper/dists

  Gradle Wrapper distributions

  Copies of Gradle that the Gradle Wrapper downloads, one for each Gradle version your projects use.

  Safe · Moves it to the Trash

• ~/**/build

  Gradle build folders

  Build output that Gradle creates for each project and module, such as compiled classes, packaged apps and test reports.

  Safe · Moves it to the Trash

• ~/.m2/repository

  Maven local repository

  Libraries and plugins that Maven has downloaded for your Java projects, plus artifacts you installed from your own projects.

  Usually safe · Moves it to the Trash

• ~/**/target

  Maven target folders

  Build output that Maven creates in each project, such as compiled classes, test reports and packaged JAR or WAR files.

  Safe · Moves it to the Trash

Seeing all of this is free. Removing it is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.