Uh oh!
There was an error while loading. Please reload this page.
Support Maven POM dependency overrides in Muzzle - #12235
Support Maven POM dependency overrides in Muzzle#12235AlexeyKuznetsov-DD wants to merge 1 commit into
Conversation
🎯 Code Coverage (details) 🔗 Commit SHA: 3fc05d4 | Docs | View more details | Give us feedback! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:3fc05d491d
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| val session = DefaultRepositorySystemSession(baseSession).apply { | ||
| repositoryListener = ChainedRepositoryListener.newInstance( | ||
| repositoryListener, | ||
| MavenDependencyVersionOverrideListener(muzzleDirective) | ||
| ) |
There was a problem hiding this comment.
Isolate the local Maven repository per override directive
When one instrumentation project declares multiple mavenPomOverrides directives that resolve a shared POM, this session clone retains the base session's LocalRepositoryManager, while the listener writes each patched POM back into that shared temporary repository. A later directive therefore reads the earlier directive's modified XML; for example, after one directive replaces 1.0 with 2.0, another directive matching 1.0 to produce 3.0 no longer matches and silently gets 2.0. This makes resolution order-dependent despite the DSL documenting overrides as directive-scoped, so each override resolution should use an isolated local repository or patch a disposable copy.
Useful? React with 👍 / 👎.
| val versionMatch = VERSION_ELEMENT.find(element, groupMatch.range.last + 1) | ||
| ?: return@replace element |
There was a problem hiding this comment.
Skip commented tags when locating dependency versions
When a dependency contains a commented-out version before its active version, such as <!-- <version>old</version> -->, this unanchored search selects and rewrites the tag inside the comment. The active bad version remains unchanged, so Maven model construction still fails even though the configured group and version selector match the dependency. The version lookup should ignore XML comments or operate on parsed XML rather than selecting the first textual <version> after groupId.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Cloning the Aether session retains its shared local repository, allowing one directive’s in-place POM rewrite to alter a later directive targeting the same artifact. The later directive can consequently resolve and validate the wrong dependency graph.
🤖 Datadog Autotest · Commit 3fc05d4 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
| baseSession: RepositorySystemSession, | ||
| defaultRepos: List<RemoteRepository> = defaultMuzzleRepos() | ||
| ): Set<File> { | ||
| val session = DefaultRepositorySystemSession(baseSession).apply { |
There was a problem hiding this comment.
Isolate rewritten POMs between directives
Muzzle can validate the wrong classpath and produce false compatibility passes or failures when named directives use different overrides for the same artifact version.
Assertion details
- Input: Two named Muzzle directives resolve the same artifact version in one project but specify different POM dependency-version overrides.
- Expected:
Each directive should apply its override configuration independently to the artifact's original published POM and resolve its own dependency graph. - Actual:
DefaultRepositorySystemSession(baseSession) retains the base session's localRepositoryManager. The override listener then rewrites the cached POM in place, so a later directive reads the first directive's modified POM; its own exact match can miss and it can resolve the first directive's dependency graph. The resolution needs a pristine per-override POM cache or restoration of original POM contents, with a multi-directive regression test.
Was this helpful? React 👍 or 👎
🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
Kafka / consumer-benchmarkParameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 3 metrics, 0 unstable metrics. See unchanged results
|
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
What Does This Do
Adds a
mavenPomOverridesDSL to Muzzle for narrowly rewriting dependency versions in downloaded Maven POMs before Aether builds the dependency graph. The DSL can:Uses the DSL for Kafka Connect and Confluent Schema Registry 7.x to replace
${jetty.version}and Jetty versions in[9.4.59,9.5)with the published9.4.58.v20250814release. This removes the Confluent skip lists so Muzzle can sample those releases normally.Motivation
Some Confluent 7.x POMs reference unpublished Jetty versions, either through an unresolved
${jetty.version}property or as flattened literal versions. Maven model construction fails before Gradle dependency resolution rules can intervene.PRs #12160 and #12172 worked around new occurrences by adding affected Confluent coordinates to Muzzle skip lists. This replaces that recurring skip-list maintenance with Confluent's suggested Jetty version workaround while retaining the repository setup introduced by #12180.
Additional Notes
POM overrides are opt-in and scoped to the declared artifact range. Generated inverse directives intentionally continue to use ordinary resolution.
Validation:
./gradlew :buildSrc:spotlessCheck./gradlew -DrunBuildSrcTests=true :buildSrc:test --tests datadog.gradle.plugin.muzzle.MuzzleDirectiveTest --tests datadog.gradle.plugin.muzzle.MuzzlePluginFunctionalTest --tests datadog.gradle.plugin.muzzle.MuzzleMavenRepoUtilsTest— 272 passed./gradlew :dd-java-agent:instrumentation:kafka:kafka-connect-0.11:muzzle :dd-java-agent:instrumentation:confluent-schema-registry:confluent-schema-registry-4.1:muzzle— 66 passedContributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: N/A