General notes

Cache tuning could significantly reduce resource consumption and build execution time, but that is not guaranteed. Performance-tuning hints might not considerably affect the build time depending on a usage pattern. As usual with performance tuning, measure results in relevant scenarios to validate results and weigh the pros and cons.

Hash algorithm selection

By default, the cache uses the XX algorithm, which is a very fast non-cryptographic hash algorithm and is sufficient for most use cases. All supported values for <hashAlgorithm> are:

<hashAlgorithm>XX</hashAlgorithm>

The memory-mapped algorithms (XXMM and those with the +MM suffix) require adding the following line to .mvn/jvm.config in the project root to run correctly on JDK ≥ 17:

--add-opens java.base/sun.nio.ch=ALL-UNNAMED

Filter out unnecessary artifacts

The price of uploading and downloading huge artifacts could be significant. In many scenarios assembling WAR, EAR or ZIP archive locally is more efficient than storing them in cache bundles. To filter out artifacts, add the configuration section:

<cache>
    <output>
        <exclude>
            <patterns>
                <pattern>.*\.zip</pattern>
            </patterns>
        </exclude>
    </output>
</cache>

Use a lazy restore

By default, the cache tries to restore all artifacts for a project preemptively. Lazy restore could give significant time by avoiding requesting and downloading unnecessary artifacts from the cache. It is beneficial when small changes are a dominating build pattern. Use command line flag:

-Dmaven.build.cache.lazyRestore=true

In cache corruption situations, the lazy cache cannot support fallback to normal execution. It will fail instead. To heal the corrupted cache, manually remove corrupted cache entries or force cache rewrite.

Disable project files restoration

By default, cache supports the partial restoration of source code state from cached generated sources (and potentially more, depending on configuration). It is helpful in a local environment but likely unnecessary and adds overhead in continuous integration. To disable, add a command line flag.

-Dmaven.build.cache.restoreGeneratedSources=false

Disable post-processing of archives(JARs, WARs, etc) META-INF

The cache could be configured to auto-correct metadata (most notably MANIFEST.MF Implementation-Version). The correction requires copying and repacking archive entries and adds overhead. If the metadata state is not relevant for the build, consider disabling it (off by default):

<cache>
    <configuration>
        ...
        <projectVersioning adjustMetaInf="false"/>
        ...
    </configuration>
    ...
</cache>