Size your Maven build cache: what it stores, in real numbers
Knowing what the Maven build cache extension uploads gives you a starting point for how much disk a shared cache needs. At FosterStack we prove everything, so here is how we proved it to ourselves: a real three-module build, every file counted, and what a fully restored build added.
The short answer
- 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 we ran
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.
| 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 also printed three [ERROR] Error downloading cache item ... buildinfo.xml lines. 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, so measure your own project before you pick a limit. To choose a size limit, see how big a server does a build cache need and how the size limit works. The same question for Gradle is on what Gradle stores in the build cache.
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 restores
See Maven build cache not restoring.
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).