Move a Maven build cache to a new server
You are replacing the machine that runs your build cache and your builds use the Apache Maven Build Cache Extension. Here is what to change, what to expect from the first build, and how to keep the cache warm. Every step was run for real with FosterStack Cache 0.2.1.
The short answer
- Change the address in
.mvn/maven-build-cache-config.xml. Nothing else in the project changes. - If you only change the address, the first build is a normal full build and fills the new server. Nothing fails.
- If you want the new server to be ready at once, stop the old one, copy its data folder, and start the new server on the copy.
What we ran
A small Maven project, Maven 3.10.0, extension 1.2.3, macOS (arm64). Every build used a fresh copy of the project and an empty local build cache, so the only thing shared was the cache server. All five builds ended with BUILD SUCCESS.
| Build | Server it used | Result |
|---|---|---|
| 1 | Old server, empty | Built the project and saved the result to the server |
| 2 | Old server, from another machine | Restored from the cache, no compile |
| 3 | New server, empty, only the address changed | Full build, saved to the new server |
| 4 | New server, from another machine | Restored from the cache, no compile |
| 5 | New server started on a copy of the old data folder | Restored from the cache, no compile |
Option 1: change the address only
Start the new server, then edit the url in the cache config and commit it. We changed this one line and nothing else:
<remote enabled="true" saveToRemote="true" id="fosterstack-cache">
<url>http://127.0.0.1:18151/</url>
</remote>
Build 3 had no cached result to find, so Maven compiled the project and saved it:
[INFO] Attempting to restore project demo:demo from build cache
[INFO] Compiling 1 source file with javac [debug release 17] to target/classes
[INFO] Saved to remote cache http://127.0.0.1:18151//v1.1/demo/demo/ebb9bceba2f7a6bc/demo.jar
From then on, every other machine pointing at the new address gets the result from the new server, as build 4 did. Anyone who still has the old address in their config keeps using the old server until they update.
Option 2: copy the data folder first
This keeps the new server warm from the first build. Stop the old server, copy its data folder, and start the new server with its data folder set to the copy. See back up and restore for why the old server should be stopped first.
cp -R data-old data-new-copied
FSCACHE_ADDR=127.0.0.1:18152 FSCACHE_DATA_DIR=$PWD/data-new-copied fscache
Build 5 found the result straight away, with no compile:
[INFO] Attempting to restore project demo:demo from build cache
[INFO] Found cached build, restoring demo:demo from cache by checksum ebb9bceba2f7a6bc
The new server's status page agreed: 2 hits and 0 misses at that point.
How to tell it worked
Look for Found cached build, restoring in the Maven output. You may also see Saved to remote cache lines on a build that restored. In our run these were a small report file that the extension saves each time, not a rebuild. If a build prints Compiling instead of Found cached build, it did not find a stored result.
Credentials and other settings
If the new server has logins, Maven reads them from the <server> entry in settings.xml whose id matches the id on the <remote> line. See Maven remote build cache setup for that, and behind a corporate proxy if your builds go through one. To move Gradle builds too, see one server for Gradle and Maven.
Run on Maven 3.10.0 with maven-build-cache-extension 1.2.3 and FosterStack Cache 0.2.1, macOS (arm64).