Infrastructure worth keeping — and kept patched.

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

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.

BuildServer it usedResult
1Old server, emptyBuilt the project and saved the result to the server
2Old server, from another machineRestored from the cache, no compile
3New server, empty, only the address changedFull build, saved to the new server
4New server, from another machineRestored from the cache, no compile
5New server started on a copy of the old data folderRestored 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).