Reuse Maven results across Muzzle modules

[sarahchen6]

What Does This Do

Plan Muzzle checks after all projects finish evaluating so that the Maven resolvers and sessions can be shared between modules with matching repo settings. Modules with custom settings are kept on their own.

Motivation

Muzzle uses the Maven Resolver library to get published dependency versions. For modules with matching repo settings, we can minimize work done by sharing the Maven results.

Additional Notes

I had Codex compare results pre and post-change. It found in a local 30-module fixture that resolver/session creation fell from 30 to 1 and median configuration + task-graph time fell from 164 to 89ms (46% improvement). All the checks and task graph were preserved. Measurements used one warmup followed by four measured warm runs per variant, alternating variant order, with offline Gradle 9.8, four workers, configuration caching disabled, a local Maven repository, and a no-op scanner.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: [PROJ-IDENT]

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.95 s	13.86 s	[-0.1%; +1.4%] (no difference)
startup:insecure-bank:tracing:Agent	12.86 s	12.94 s	[-1.3%; +0.2%] (no difference)
startup:petclinic:appsec:Agent	17.72 s	17.47 s	[+0.4%; +2.4%] (maybe worse)
startup:petclinic:iast:Agent	17.40 s	17.52 s	[-1.5%; +0.2%] (no difference)
startup:petclinic:profiling:Agent	17.03 s	17.45 s	[-7.0%; +2.1%] (no difference)
startup:petclinic:sca:Agent	17.77 s	17.72 s	[-0.6%; +1.1%] (no difference)
startup:petclinic:tracing:Agent	16.19 s	16.71 s	[-7.2%; +1.1%] (no difference)

Commit: d82e4291 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-08T20:08:37.466290Z	c4923c9	Draft marked ready
🔒 Security Review	✅ Completed 2026-10-08T20:09:23.919316Z	c4923c9	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[datadog-official]

More details

Static review found no reportable defect in deferred planning, repository isolation, Maven caching, or task wiring. Gradle execution and the claimed performance improvement remain unverified.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit c4923c9 · @DataDog review to ask questions}

[dougqh]

Looks good -- sharing the session is safe here (it's only used serially during configuration, and the retry path already bypasses cached failures with fresh session data). Two non-blocking comments:

1. Shared state: rather than a raw MutableMap in rootProject.extensions.extraProperties with an unchecked cast, consider a shared BuildService to hold the planners. It's typed, lifecycle-managed by Gradle, and won't get in the way if we ever enable isolated projects.

2. projectsEvaluated: is the later timing needed? Sharing via the map would also work from each project's afterEvaluate, since the root project is evaluated first. If it's mainly for the "planning sees directives configured after project evaluation" case, note that test relies on the root's projectsEvaluated callback being registered before the module's. If the later timing isn't needed, keeping afterEvaluate seems simpler; if it is, a sentence in the description on why would help.

[datadog-official]

More details

Static review supports repository isolation when sharing Maven planners and found no concrete regression in deferred planning or aggregate task selection.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit c4923c9}

[bric3]

issue: I'd avoid the extra properties here. It's not typed, and the access is not coordinated, it happens via hasProperty / setProperty which looks like configuring another project.

Maybe a service could better fit? I'm unsure at this stage.

[bric3]

note: This is a long type. Maybe using a kotlin type alias or a concrete value class for the key could help. Also that's the issue with extra properties it's not typed.

Also, I think using the map directly here could burn us.

I tend to think that making the whole thing a service offering some method. E.g. a registrar that return a planer. Or even higher level method returning a MuzzleValidationTasks.