Enable build caching using develocity

[timja]

This enables local build caching for the built-in supported goals. Primary benefit is caching of compilation for modules, especially the CLI module.

Savings seem worth it to me, works well in my testing.

Note

Requires #27162 for the biggest benefit

A full build using cache and mvnd:

[INFO] Total time:  14.907 s (Wall Clock)
[INFO] Finished at: 2026-07-28T21:58:10+01:00
[INFO] ------------------------------------------------------------------------
[INFO] 170 goals, 164 executed, 6 from cache, saving at least 1s

Note

Homebrews latest version of mvnd (1.0.2) doesn't support develocity
Grab a newer one from GitHub releases

---

Full build using cache and plain mvn:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  20.689 s
[INFO] Finished at: 2026-07-28T21:47:50+01:00
[INFO] ------------------------------------------------------------------------
[INFO] 170 goals, 164 executed, 6 from cache, saving at least 14s

Fixes #

Testing done

• Changed source files verified updates apply
• mvn jetty:run

I also tried https://maven.apache.org/extensions/maven-build-cache-extension/ but it wasn't working with jetty:run

Screenshots (UI changes only)

Before

After

Proposed changelog entries

• human-readable text

Proposed changelog category

/label

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[timja]

Tested with:

CI=true mvn clean install -P quick-build

Caching no longer occurs

[timja]

License appears to be: https://develocity.ai/legal/gradle-technologies-terms-of-use/

any thoughts?

We aren't bundling it, it just provides faster builds.

---

If its a dealbreaker I can go back to trying to get the apache one to work but this was a lot simpler

[MarkEWaite]

any thoughts?

Gradle shared Develocity build caching with me and some others a while ago. They indicated that it has significantly reduced build times for those Apache projects that use it. I think we should use it. They intend for it to be used by open source projects, as far as I can tell.

[Copilot]

Pull request overview

This pull request introduces Develocity’s Maven extension and configuration to enable build caching for local development builds, and updates the parent POM version.

Changes:

• Add com.gradle:develocity-maven-extension to Maven core extensions.
• Add .mvn/develocity.xml to enable the local build cache (currently gated by environment).
• Ignore Develocity’s local state directory under .mvn/.develocity/, and bump the parent POM version.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

File	Description
pom.xml	Updates the parent POM version (potentially broad impact beyond caching).
.mvn/extensions.xml	Adds the Develocity Maven extension to enable build caching features.
.mvn/develocity.xml	Configures Develocity build cache enablement logic.
.gitignore	Ignores Develocity’s local directory under .mvn/.develocity/.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

.mvn/develocity.xml:10

• <onlyIf>false</onlyIf> disables build scan publishing unconditionally, so running Maven with -Dscan (as the comment suggests) will still never publish a scan. If the intent is “publish only when -Dscan is provided”, make onlyIf conditional on the presence of the scan system property.

      <!-- if you want a build scan, pass -Dscan on the command line -->
      <onlyIf>false</onlyIf>

[Copilot]

Pull request overview

Copilot reviewed 2 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

.mvn/develocity.xml:10

• The comment says scans can be enabled with -Dscan, but onlyIf is currently hard-coded to false, so build scans will never be published even when -Dscan is passed. Use a property-based condition so the comment matches the behavior.

      <!-- if you want a build scan, pass -Dscan on the command line -->
      <onlyIf>false</onlyIf>

[Copilot]

Pull request overview

Copilot reviewed 2 out of 3 changed files in this pull request and generated no new comments.

[MarkEWaite]

Saves time on my build as well.

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process.

/label ready-for-merge