Cleaning Gradle and Maven build directories

target/, build/ and .gradle/ rebuild from the project beside them. The local repository at ~/.m2 does not, and treating it as a cache is how artifacts vanish.

Updated 2026-09-20

Short answer: the per-project build trees are safe to delete. Maven's target/ comes back on the next mvn package. Gradle's build/ and .gradle/ come back on the next build. sbt's target/ and project/target/ likewise. Everything in them is compiled from the sources and the build file sitting beside them, and on a JVM project of any age they are usually the largest directories in the repository.

What they cost to delete is not download time but compile time. A node_modules returns as fast as the network allows; a build tree returns as fast as your machine compiles, which on a large project is the difference between seconds and minutes. That distinction matters later.

The machine-wide stores are a different question

Outside the repository, both tools keep shared state under your home directory, and the two are not equally safe.

Gradle's is a cache. ~/.gradle/caches holds downloaded dependencies and build metadata; ~/.gradle/wrapper/dists holds the Gradle distributions your wrappers have fetched. Both are re-downloaded on demand. Deleting them costs every Gradle project on the machine one cold start, and nothing else.

Maven's is not. ~/.m2/repository is called the local repository, not the cache, and the name is load-bearing. mvn install writes your own builds into it. mvn install:install-file is the documented way to use a jar that exists in no remote repository at all, which is how a database driver behind a click-through licence or a partner SDK ends up there, with no origin to fetch it back from. Your -SNAPSHOT builds live there and nowhere else. Emptying it as if it were a download cache deletes the recoverable majority and the unrecoverable minority together, and you find out which was which at the next build failure.

How dev-prune handles the pair

In dev-prune, Gradle and Maven are opt-in adapters, off by default like every adapter whose directories come back by recompiling rather than downloading. Turning one on is one setting:

devp config set enable_gradle true
          devp config set enable_maven true

An enabled build adapter waits for the longer idle window (45 days by default, against the usual 15) before its directories become candidates, so a project you build weekly keeps its warm build tree and a repository untouched since spring gives its tree up. Every directory is still verified against the project file beside it before deletion, and a dry run of devp run ends by naming any build adapters that are switched off but would have found something.

The machine-wide stores follow the split above. devp caches sizes both. devp caches clear gradle empties Gradle's caches and wrapper distributions, after showing what would go and asking. devp caches clear maven is refused outright: it exits with a usage error, explains that the local repository holds artifacts no remote can restore, and prints the rm -rf line so that if you want that space, the decision and the keystroke are both yours.