[Mikola Lysenko (mikolalysenko)]

Stacked on #2020. This closes the last Maven property false-attestation gap in VEX discovery: a <groupId> / <artifactId> written as ${prop} that a profile's <properties> redefine. Hosted scan gets the same refusal, and so does the v5 vendored planner.

The gap

Coordinates were resolved only with no profile active. Discovery therefore attested two shapes the build may not resolve:

• (a) The declaration carrying the pin names another package whenever a profile that redefines its coordinate property is active. The pin then no longer applies to the patched GA, which resolves from its other declarations or transitively, unpinned.
• (b) Another declaration turns into the patched GA under a profile, at its own version, which isn't the pin. This covers both a live declaration and one inside a profile whose own properties retarget it.

Fix

• formats/maven: coordinates now go through Resolve Maven pin properties through profiles and nesting #2020's shared helpers.

  • resolve_in_build is now a wrapper over resolve_all_in_build. That function reads a declaration's groupId, artifactId and version under the same profile combinations, with each text on its own interpolation (interpolate_keeping for coordinates, interpolate_strict for the version) and its own work budget. profile_combinations takes all three texts.
  • PomDep::coordinate_alternatives holds each reading whose coordinates differ from the no-profile reading, with its version and the profiles that cause it. A profile declaration's reading under its own profile counts too.
  • More than 8 relevant profiles, or profile <properties> that can't be parsed, fail closed: the text as written becomes the reading.

• vex/discover/maven: bypasses() treats each such reading as a declaration of its own (retargeted()), active only under those profiles and at the version it resolves there. The existing checks then weigh it: unpatched_classifier_copy (with the Wiring) and profile_override.

  • Its <type> is read the way Maven maps it, consistent with may_shadow: test-jar is the tests classifier copy, and any other non-jar type isn't a jar on the classpath.
  • (a) is the one remaining dedicated check, pin_retargeted.
  • Details name the declaration as written and the profiles that retarget it.

• vendor/jvm/maven_reactor: the v5 planner had the same gap.

  • read_elsewhere and profile_override read several texts under one combination, each on its own budget. version_override and coordinates_elsewhere both use them.
  • (a) The existing coordinates_overridden check now covers profiles as well as inheritors.
  • (b) warn_property_coordinates is one pass over the property-coordinate declarations. It first rules out text that can never name the GA (may_interpolate_to), then sorts each remaining declaration into unresolved (property_unresolved) or moved under a profile or inheritor (coordinates_overridden). Both share one warn-and-unpin tail. An executable classifier copy gets classifier_declared, as a literal one does.

• Hosted (back-port): PomIndex now reads profile <properties> and each declaration's coordinate_alternatives. rewrite_maven_pom refuses the dep, writing nothing, in two cases:

  • the declaration the pin would go into moves off the GA under a profile;
  • another declaration becomes the GA's main jar at another version, or an executable classifier copy of it.

  The warning is redirect_maven_profile_coordinates_unpatched, documented in CLI_CONTRACT.md. scan therefore never writes a pin that vex would withhold for this reason. The vex_maven_profile_unpatched note no longer suggests re-patching such a pin with vendored mode.

• Hosted, profile versions (back-port): hosted already refused a live ${property} version, but it still pinned a live declaration that had a versioned <profiles> declaration of the GA beside it, and discovery then withheld that pin forever. PomIndex now records each declaration's managed flag and every version the build may resolve for it, using resolve_in_build with interpolate_strict, the same data discovery reads. PomIndex::profile_bypass mirrors discovery's profile_override check.

  • When it finds a bypass, the dep is refused with nothing written, under the existing redirect_maven_profile_dependency_unpatched code.
  • Shapes covered: a profile literal at another version; a profile ${property} that is undefined, or that its own or any combination of profiles' <properties> move off the pin; a profile declaration through an undefined coordinate property; and a profile <dependencyManagement> entry where management governs the pin.
  • The pin still lands for a versionless profile declaration, one that resolves the pin, or profile management under a direct pin.

• Hosted, classifier copies (back-port): hosted used to skip a dep only when an executable classifier copy named the patched release. PomIndex::unserved_classifier_copy now mirrors discovery's unpatched_classifier_copy, using the shared is_executable_classifier and each declaration's build_versions.

  • The dep is refused with nothing written, under the existing redirect_maven_classifier_unsupported code, when an executable copy may resolve anything but the suffixed pin.
  • That covers a copy live or in <profiles>, and versions that are another release, a ${property} a profile moves, or none in the pom once its classifier-keyed <dependencyManagement> (a profile's too) is consulted.
  • sources / javadoc copies still only warn. A test-jar typed declaration stays refused as an unsupported packaging, or as a profile bypass.

Tests

Each of these fails before this change, or with the fix disabled:

• vex::discover::maven::tests::profile_properties_moving_the_pinned_coordinates_are_not_attested
• vex::discover::maven::tests::profile_properties_turning_a_declaration_into_the_pinned_ga_are_not_attested. New cases: test-jar is withheld; war, and coordinates plus version moved onto the pin together, are attested.
• vex::discover::maven::tests::vendored_ref_under_a_retargeted_classifier_copy_is_not_attested
• vendor::jvm::maven_reactor::tests::a_profile_moving_the_declared_coordinates_is_left_alone
• vendor::jvm::maven_reactor::tests::a_profile_turning_a_declaration_into_the_patched_artifact_is_weighed
• vendor::jvm::maven_reactor::tests::many_profiles_on_an_unrelated_coordinate_are_not_weighed
• vendor::jvm::maven_reactor::tests::a_profile_retargeting_a_classifier_copy_warns
• patch::redirect::tests::maven_pom_profile_moved_coordinates_refuse_the_dep
• patch::redirect::tests::maven_executable_classifier_off_the_pin_blocks_the_redirect
• patch::redirect::tests::maven_profile_versions_are_weighed_before_pinning. Also updated: maven_versioned_profile_declarations_are_never_pinned_over and maven_pom_undefined_coordinate_property_in_a_profile_is_reported, which asserted the old behavior of pinning beside a profile declaration.
• formats::maven::tests::profile_properties_give_coordinate_alternatives, including an unterminated ${ in one coordinate.

The guard test is unrelated_coordinate_properties_do_not_withhold. The user-property variants are inside each test. The redirect goldens (tests/redirect_golden.rs) and the VEX golden corpus are unchanged.

Review findings (/code-review high)

1. Confirmed, fixed. A classifier copy retargeted onto the GA is now weighed by unpatched_classifier_copy with the Wiring. Under the pre-v5 vendored repository it is withheld even at the vendored version.
2. Confirmed, fixed. warn_property_coordinates filters with may_interpolate_to on the raw text before any inheritor or profile walk, so the >8-profile fail-closed path only applies to text that could name the GA. The reactor's profile_override still fails closed whatever moved says; the filter is the caller's job, as its doc now states.
3. Confirmed, fixed. A retargeted executable classifier copy gets classifier_declared, without unpinning the root. That is the same treatment as a literal copy in rewrite_declarations. sources / javadoc copies are still not warned about.
4. Confirmed, fixed by the same filter as (2), which runs before coordinates_elsewhere.
5. Confirmed, fixed. The U+0001 joined text is gone. Each text has its own interpolation budget, an unterminated ${ stays in its own coordinate, and every reading names a non-empty profile set: combinations are non-empty, and an own-profile reading is added only when that profile exists.
6. Done. coordinate_override is removed. Readings are expanded into per-combination declarations and go through the existing checks, which closes (1) and the "coordinates and version both moved onto the pin" gap. Only the "pin moves off the GA" case keeps its own small check, because no existing check looks for a pin disappearing.
7. Done. The two warn passes are merged into warn_property_coordinates.
8. Confirmed, fixed for retargeted readings in both discovery (retargeted()) and hosted (PomIndex::retargeted). A literal-coordinate declaration's type handling is Fix Maven VEX false attestation through profiles, properties and coordinates #2005's and is unchanged.
9. Done. This is the hosted back-port described above. A follow-up commit closes the version shape as well: hosted no longer writes a pin that a profile declaration's version (literal, or moved by <properties>) bypasses.

Not done

• In the vendored reactor, a declaration's coordinate readings and its version are not matched per combination. Like the existing undefined-coordinate rule, any versioned declaration that may become the GA unpins its root.
• In vendored mode, an executable classifier copy (literal or retargeted) still only warns. attestable_checked does not withhold for it. This predates this PR (rewrite_declarations' classifier_declared).

Brought current with #2020, plus round-2 review findings (cloud routine)

Merged the updated #2020 (3389c34) in as c82973f. Conflicts:

• CLI_CONTRACT.md rows: resolved to keep both sides.
• The hosted classifier-variant loop: kept this PR's version.
• ScopedDep coordinates: combined with Resolve Maven pin properties through profiles and nesting #2020's change.

#2020 round 2 made a profile declaration's coordinates read its own profile's <properties>. This PR had read them with no profile active instead. Round 3 below reverts that, so the declaration's own profile is read again.

Review findings, round 2 (/code-review high on c77d5d5..402fccf)

1. FALSE ATTESTATION: a retargeted declaration with a type and an explicit classifier was dropped. Confirmed and fixed. test-jar + <classifier>tests</classifier> fell through to "any other type: not weighed" in both discovery's and the hosted index's retargeted. Hosted scan wrote the pin and VEX attested it, while the active profile put the unpatched tests jar on the classpath. An explicit classifier now names the copy whatever the type. Tests: profile_properties_turning_a_declaration_into_the_pinned_ga_are_not_attested and maven_pom_profile_moved_coordinates_refuse_the_dep, both extended. Both failed without the fix.
2. Contract wording on the retargeted classifier copy in vendored mode: fixed. It now says this case is reported as classifier_declared with the root still pinned.

Declined:

• Hosted retargeted ignores managed / pin_managed, so it refuses some pins VEX would attest. This over-refuses, which is the fail-safe direction. The proper fix is the single shared implementation the reviewer suggests, which is a refactor.
• Version-only profiles now count toward the 8-profile cap for coordinates. This also over-refuses.
• set_version leaves build_versions stale. No current caller reads them after an edit. Worth fixing in the refactor.
• Clones, doc.coordinate reuse and the loosened kind assertion. These are performance and test style.

Tests (cloud run): cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect:: vendor::jvm gives 1611 passed, golden included. The 1 failure is the chmod test, which root ignores. CLI --lib vex_sources passes. clippy and fmt are clean.

Review findings, round 3 (/code-review high after merging current #2020 / main)

Merged #2020 (ddf4808) in as 791ded0, with a doc follow-up in 237307e (its no-profile wording is superseded by finding 1). Fixed in 37d9fd9:

1. Regression, confirmed and fixed (over-refusal). A <profiles> declaration's ${…} coordinate was read with no profile active, and its own profile's reading was only an alternative. A groupId that only its own <properties> define therefore stayed ${g}, which may_name reads as any text. VEX withheld, and hosted scan refused, a valid pin that sat beside a profile dependency naming another group. Coordinates now read the declaration's own profile again, as its version does, and other profiles stay alternatives.
   • Tests: a new case in unrelated_coordinate_properties_do_not_withhold and in maven_pom_profile_moved_coordinates_refuse_the_dep. Both failed without the fix.
   • The own-profile case in profile_properties_turning_a_declaration_into_the_pinned_ga_are_not_attested is still withheld (MavenProfileUnpatched). It is now asserted on its own, because the detail names the declaration as a profile declaration of the GA. The formats expectation is updated to match.
2. Vendored parity, confirmed and fixed. warn_property_coordinates skipped a ${…} <type>, which discovery and the hosted index read as possibly jar. As a result, vendored mode pinned a root that VEX never attests, and nothing explained why. It is weighed now. Test: a_profile_turning_a_declaration_into_the_patched_artifact_is_weighed, which failed without the fix.

Declined:

• An executable classifier copy at exactly the suffixed version is no longer refused by hosted. This was deliberate: maven_executable_classifier_off_the_pin_blocks_the_redirect lists it under pinned, mirroring how discovery's unpatched_classifier_copy treats served. It can't attest unpatched code either, because the hosted repo serves only the main jar, so such a copy fails resolution loudly. Any rewriter run hits the same failure, and that failure exists before the scan.
• Hosted retargeted ignores managed / pin_managed. This over-refuses, and was declined in round 2.
• The legacy same-GAV path passes served = None to retargeted. This over-refuses. Passing dep.version would also let through a retargeted executable classifier copy, which the legacy repository doesn't serve either.
• may_interpolate_to rejects an unterminated ${. Maven reads an unterminated ${ literally, so "${g" can never be the GA. The reactor is right here; VEX and hosted only over-refuse.
• The type→copy mapping is repeated in three places. This is a refactor. The one parity bug it caused (2) is fixed.
• Eager PomIndex combination work and PomDep clones in bypasses(). These are performance.

Coherence check requested by the owner, read on the merged stack:

• The rewriter writes and rolls back through the pom-spelled version.
• Discovery compares the spelled and build-resolved versions, and a .mvn/maven.config -D that moves the pin off is MavenConfigOverride.
• Hosted refuses a live ${property} version outright.
• Profile moves (MavenProfileUnpatched) and classifier copies are weighed on build-resolved versions in both discovery and the hosted index.

No incoherence found.

Tests on 37d9fd9: cargo test -p socket-patch-core --lib -- maven vex:: patch::redirect:: passes 1964, redirect_golden passes, CLI --lib vex_sources passes, and the CLI vex, e2e_vex, cli_parse_vex and vendor_jvm_cli tests pass. Workspace clippy and fmt are clean.

---

Note

Medium Risk
Changes hosted Maven redirect and VEX attestation logic in lockfile-writing paths—fail-closed (fewer pins written) but affects build wiring decisions for profile-heavy POMs.

Overview
Maven POM resolution under profiles now reads groupId, artifactId, and version together per active profile combination, recording coordinate_alternatives when profile <properties> retarget coordinates.

Hosted scan (scan --mode hosted) stops writing pins that VEX would not attest:

• redirect_maven_profile_coordinates_unpatched when a ${…} coordinate a profile redefines would move the pin off the GA or turn another declaration into the patched artifact (including executable classifier copies such as test-jar + explicit classifier).
• Existing classifier/profile codes now refuse the dep (no pom.xml write) when an executable classifier or a profile declaration/management can resolve any version other than the suffixed pin—not only when they name the base release.

CLI contract and VEX notes document the stricter hosted behavior and extend vex_maven_profile_unpatched messaging for coordinate property redefinition (vendored mode no longer suggested as a fix when profiles bypass the pin).

Core parsing (formats/maven, PomIndex) and redirect tests back the new fail-closed checks; behavior stacks on the shared profile-resolution work from the parent branch.

^{Reviewed by Cursor Bugbot for commit a8541ab. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merged the rewritten base (#2020 was force-pushed to ec89bd9) into this branch at 9ce83ae. Conflicts resolved against the old base d7b4b40, so only this PR's change was re-applied on top of the base's new structure:

• coordinate_override now runs from bypasses after profile_override (the base replaced the old declaration_override), and reads build_version and is_executable_classifier like the base's checks.
• coordinate_alternatives' no-profile baseline calls lookup(name, &[], true) (user properties included), matching lookup_any.
• CLI_CONTRACT.md and the profile note keep both sides' wording.

Local: cargo check core+cli clean; cargo test -p socket-patch-core --lib maven 361/361, including this PR's four regression tests. Still a draft, so it stays unlabeled.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merged the base fix/maven-discovery-property-overrides (84967b1) into this branch as 74fa073 to clear the merge conflicts.

The base had picked up main's Maven variant refactor (#2006), where a <type> such as test-jar counts like the classifier it implies. Conflicts were in redirect/mod.rs, maven_reactor.rs, vex/discover/maven.rs and CLI_CONTRACT.md, and both sides are kept. One semantic follow-up was needed: MavenIndex::unserved_classifier_copy now weighs every executable variant, typed ones included, with management keyed by classifier and type. Without that, the base's maven_executable_classifier_variant_blocks_the_redirect test (a test-jar copy) failed.

Local run: cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect:: vendor::jvm gives 1666 passed. The 1 failure is the vlt_heal chmod test, which root ignores. CLI lib tests pass (865).

Worth a reviewer's look: retargeted() in discover still drops a retargeted declaration whose type is neither jar, test-jar nor explicitly classified (for example ejb), while the base's variant rule counts such types as executable.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit a8541ab. Configure here.}

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Review findings (Claude Opus + codex, independent passes):

1. Retargeted executable variants are dropped (crates/socket-patch-core/src/vex/discover/maven.rs:898; same in patch/redirect/maven_index.rs:280 and vendor/jvm/maven_reactor.rs:2318; Opus). retargeted() discards a profile-moved reading for any <type> other than jar/test-jar/${…}/explicit classifier — including ejb, ejb-client, maven-plugin, bundle, which is_executable_variant (formats/maven/mod.rs:984-1000) treats as code. Input: hosted pin org.slf4j:slf4j-api:1.7.36-socket.<hex> plus ${g}:slf4j-api:1.7.30 with <type>ejb</type>, root g=org.other, profile p sets g=org.slf4j → scan pins and vex attests, while -Pp puts unpatched slf4j-api-1.7.30 on the classpath. The literal-coordinates version of the same pom is withheld. Suggested fix: map retargeted types through is_variant/is_executable_variant in all three places instead of a hand-written allowlist.
2. Management precedence ignored in hosted retargeted() (maven_index.rs:298, codex; fail-safe). Direct slf4j-api:1.7.36 plus managed ${g}:slf4j-api:1.7.30 with a profile retargeting g makes hosted scan write nothing, though the direct version wins under every profile; discovery already excludes it.

Minor: hosted unserved_classifier_copy matches only literal coordinates while discovery uses may_name (hosted pins, VEX withholds forever).

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Approving per maintainer decision; see the findings in the review above.

[Mikola Lysenko (mikolalysenko)]

Not merged to main. GitHub marked this merged because the stack was folded: fix/maven-discovery-false-attestation was fast-forwarded to this PR's head. The whole Maven stack is now reviewed and landed as #2005.