Gradle should have some housekeeping functionality

It would be nice if Gradle had something comparable to brew cleanup, i.e. some functionality that would delete everything not “owned” by the currently executing Gradle instance.

A naive implementation would do the following, assuming executing Gradle version is 3.3:

  • Delete everything in <projectdir>/.gradle beside <projectdir>/.gradle/3.3.
  • Delete everything in ~/.gradle/wrapper beside ~/.gradle/wrapper/dists/gradle-3.3-all and/or ~/.gradle/wrapper/dists/gradle-3.3-bin.
  • Delete everything in ~/.gradle/daemon beside ~/.gradle/daemon/3.3.
  • Delete whatever is reasonable in ~/.gradle/native.
  • Delete everything Gradle version related in ~/.gradle/caches, i.e. keep ~/.gradle/caches/3.3, ~/.gradle/caches/jars-2 and ~/.gradle/caches/modules-2.
    • Optionally, delete “outdated stuff” from jars-2 and modules-2. This could be a separate step. With “outdated stuff” I mean something like “only keep the most recent version of each and every dependency” and purge everything else from the respective cache. It’s not too problematic if something is purged that is actually still needed since it would simply be downloaded during the next build.
  • Finally (and this is important): Brag about the disk space this operation freed up.

We currently do something like the above by periodically executing a script like this on our build server:

rm -rf ~/.gradle/daemon/*
rm -rf ~/.gradle/caches/*
rm -rf ~/.gradle/native/*
rm -rf ~/.gradle/task-cache/*
rm -rf ~/.gradle/wrapper/*

But this is too greedy. It deletes everything instead of just the outdated parts, causing another “downloading the internet” episode afterwards.

I don’t think that this is functionality suitable for a third-party plugin because everything touched is essentially a Gradle implementation detail. Only you know how to do this properly and without accidentally introducing side effects like a corrupted cache.


This is somewhat related to issue #1085/GRADLE-2267.

I have a similar issue. I made this post a while back with a similar wish to expose a snapshot purge, no response…

Hi Jörn,

The clean task would be nice, but it would remove files from other projects too.
Don’t remove the ~/.gradle/wrapper directory, it have only cache of the gradle installation for the gradlew build script.

For a faster download of the jar files, you should create a local network maven repository, update the script to download the jar from there:

repositories {
maven { url “${artifactory_contextUrl_libs_release}” }

The variables are defined in the ~/.gradle/


I have a local jar repository, it have the cache of all used jars:

if you have several external maven servers, you just add the server on the Artifactory server configuration, it will download and cache all the jar files from all remote servers, your local script only need to define 1 maven repository. After the first download, all new download from the jar will take the time of a local network copy.

Kind regards
Edson Schlei

Oh yes, I’m aware that other project snapshots would also be cleaned. That’s more or less the idea.

Everything cached can be recreated anyway or if that isn’t the case then I’d like to know about that, too.

We are already using an in-house snapshot repository with a similar cleanup strategy regarding old snapshot files. That repo is also caching the non-snapshot files… “downloading the internet” was only meant figuratively for “downloading a lot of stuff”.

Thanks for your answer anyway. I appreciate the feedback and the effort you put into it.

Deleting ~/.gradle/wrapper isn’t saving that much but even those wrappers accumulate over time since I routinely check every RC and sometimes even nightlies.

But all that pales in comparison to the snapshot buildup in caches. Let’s not forget about non-snapshot dependencies that have been updated over time, either. All the old (and now unused) versions will still remain in caches forever.

Having an “official” way of cleanup would be a significant plus in my opinion.

1 Like