What does the build cache store? Gradle and Maven
Knowing what Gradle and Maven put in the cache tells you what you are paying disk for. We ran real Gradle and Maven builds against FosterStack Cache and counted every entry.
The short answer
Gradle
- Each
compileJavatask stored one entry. - Gradle also compiled the build scripts, and those compiled scripts were stored as entries. That is why there are more entries than compile tasks. In a run where the Gradle home had already compiled the scripts, they were not stored again.
- The jar, classes, assemble and build tasks stored nothing in our run.
- The 13 entries from a four-module build took about 36 KB.
Maven
- Each built module uploaded two files: its jar (about 5 KB here) and a
buildinfo.xml(about 9 KB here). - Both of our builds also uploaded one
build-cache-report.xml. - Our three-module build left 7 entries and 44,810 bytes on an empty server.
- A second build that restored every module added just that one entry, the report.
What to do
Our advice, not a test result. Measure your own project before you pick a limit. The server's status page (/statusz) shows the entry count and the size in bytes. To see how it changes as you build, see is my build cache server healthy, and what to alert on. To pick a size limit, see how big a server does a build cache need and how the size limit works.
Gradle: what one build stored
What the 13 entries were (Mac run)
| Stored | Entries |
|---|---|
:core:compileJava | 1 |
:util:compileJava | 1 |
:api:compileJava | 1 |
:app:compileJava | 1 |
| Kotlin build script compilation, first stage | 5 |
| Kotlin build script compilation, second stage | 4 |
These are the lines Gradle printed:
Stored cache entry for task ':core:compileJava' with cache key ...
Stored cache entry for Kotlin DSL script compilation (Project/TopLevel/stage1) with cache key ...
Stored cache entry for Kotlin DSL script compilation (Project/TopLevel/stage2) with cache key ...What was not stored
These tasks ran and stored nothing: classes, jar, assemble and build for each of the four modules. In our other runs the jar tasks never printed FROM-CACHE either. In our builds you will see them run on every fresh checkout.
See it for your own build
Start from an empty cache, run your build once with -i, and count. We ran exactly this command, with the output saved, and it printed the same 13 entries:
gradle build -i | grep "Stored cache entry"If your Gradle home has already compiled your build scripts, you will not see the script entries again: in a second run with the same Gradle home against a new empty server, only the 4 compileJava entries were stored, and the server held 4 entries and 11,425 bytes.
Size your Maven build cache: what it stores, in real numbers
Entries and bytes after each build
| Step | Entries on the server | Bytes |
|---|---|---|
| Empty server | 0 | 0 |
| After the first build (all three modules built) | 7 | 44,810 |
| After a second build from a fresh copy (all three restored) | 8 | 46,128 |
The 7 entries from the first build
| File | How many | What it is |
|---|---|---|
core.jar, util.jar, app.jar | 3 | The built jar of each module (5,028 to 5,340 bytes each) |
buildinfo.xml | 3 | A record for each module that the next build looks up first (9,007 to 9,332 bytes each) |
build-cache-report.xml | 1 | A report about the build run itself |
The key is shortened to <key> here:
[INFO] Saved to remote cache http://127.0.0.1:18180//v1.1/demo/core/<key>/core.jarWhat a restored build adds
The second build restored all three modules and built nothing, and it uploaded one file: build-cache-report.xml. So our fully restored build still added one entry, 1,318 bytes (46,128 minus 44,810). We saw two builds, so we cannot say whether every restored build does the same.
On the first build, against an empty server, Maven 3.10.0 also printed three [ERROR] Error downloading cache item ... buildinfo.xml lines (Maven 3.9.9 logs these misses as [INFO] Cache item not found). Those were ordinary misses on an empty cache, and the build succeeded; see enable or disable the Maven build cache extension.
What this means for sizing
In this tiny project the buildinfo.xml files were bigger than the jars: about 9 KB each against about 5 KB, and together 27,661 of the 44,810 bytes. We did not test how that balance changes with large jars.
We tried one small project with jars of a few kilobytes. We did not test large jars, many versions of the same module, or a project with test reports.
If you do not see what you expect
Look at why the hit rate is low and enable or disable the Gradle build cache. A task that stored nothing in your build, such as the jar tasks in ours, could not come from the cache.
See Maven build cache not restoring.
How we checked
Gradle. The four-module build from Gradle build cache for a monorepo: core, util, api and app, each with 12 small Java classes and a Kotlin build file. Our first run used a project folder that still held build output from an earlier check; we repeated it, with the same 13 entries, from a clean copy and got the same results. We started a new, empty server and ran gradle build --console=plain --no-daemon -i once, with the local cache off and a new, empty Gradle home. The -i flag makes Gradle print a line each time it stores something. The build ended with BUILD SUCCESSFUL. The project has no tests, so there are no test entries here; for those, see Gradle test task FROM-CACHE.
The server's status page then said: 13 entries, 36,054 bytes. When we repeated the run, the entry count was the same and the size varied by a few dozen bytes (36,054 to 36,103 across our runs).
Maven. The three-module project from Maven build cache extension in a multi-module project: core, util and app. We started a new, empty server and ran mvn verify twice, each time from a fresh copy of the project with an empty local build cache. Both builds ran on the same Mac and shared one already-filled local Maven repository, offline (-o -B, plus options for the repository and the local cache location). Both ended with BUILD SUCCESS. In our runs the extension printed one Saved to remote cache line for each entry that ended up on the server, and the server's status page (/statusz) gave the counts.
Run on Gradle 9.8.0 with FosterStack Cache 0.2.1, macOS (arm64), Java 27.
Run on Maven 3.10.0 with maven-build-cache-extension 1.2.3 and FosterStack Cache 0.2.1, macOS (arm64), Java 27 (Homebrew).
Second run: Linux, 0.2.2 (the Gradle half)
We ran the four-module Gradle build again on a GitHub-hosted Linux machine with FosterStack Cache 0.2.2, Gradle 9.8.0 and Java 21. We wrote the build files again, because they are not shown here, so the counts differ a little from the Mac run: 12 entries here, 13 there.
gradle build -iprinted 12Stored cache entrylines, not 13: onecompileJavaentry for each of the four modules, 5 entries for the first stage of build script compilation and 3 for the second. The server held 12 entries and 29,821 bytes.- The
classes,jar,assembleandbuildtasks of the four modules stored nothing and never came from the cache. - A second run with the same Gradle home against a new empty server stored only the 4
compileJavaentries: 4 entries and 8,386 bytes.
The Gradle half: the run and its log are public.
Second run: Linux, 0.2.2 (the Maven half)
The Maven runs above were on a Mac with 0.2.1. We ran the three-module build again on a GitHub-hosted Linux machine with FosterStack Cache 0.2.2, Maven 3.10.0 and Java 21.
- The first build against an empty server saved 7 entries: 3 jars, 3
buildinfo.xmlfiles and 1build-cache-report.xml, with three[ERROR] Error downloading cache item ... buildinfo.xmllines for the misses. - The 3 jars came to 10,077 bytes in all (about 3.4 KB each; the Mac run: about 5 KB each). The 3
buildinfo.xmlfiles came to 27,781 bytes, about the same as on the Mac. The server held 39,311 bytes (the Mac run: 44,810). Thebuildinfo.xmlfiles were again bigger than the jars. We downloaded each saved file from the server to measure it, and the sizes added up to the server's number. - A second build from a fresh copy restored all three modules and added one entry, the report, of 1,318 bytes, the same size as on the Mac.