[Mikola Lysenko (mikolalysenko)]

Stacked on #2005, including its review fix (9765178). This closes the two Maven false-attestation gaps #2005 left open in VEX discovery. It also gives VEX discovery and the vendored planner one property resolver.

1. Profile <properties> redefining a pin's property

Take a live <version>${v}</version> whose build resolution is the Socket pin. If a profile's <properties> redefine v, or any property v names, Maven resolves something else while that profile is active. Maven activates any number of profiles together, so combinations count too. Vendored mode refuses to pin over such a property (version_override), but discovery attested it.

• parse_pom_with reads every profile's <properties>. PomScope::resolve_in_build then lists each value a combination of profiles gives the version.
  • Only the profiles that define a name reachable from the version are combined, at most 8; past that it fails closed.
  • Each combination is resolved as one property view: the profiles are merged over the pom's own, and a later profile wins.
  • User properties and model references that the model answers stay fixed.
• Each PomDep carries those values as version_alternatives, smallest combination first. Each alternative records the profile ids that give it.
• In discovery, the resolutions(d) helper plugs these into Stop attesting Maven pins a profile or user property overrides #2005's helpers in three places:
  • unpatched_classifier_copy: classifier copies and their classifier-keyed management.
  • profile_override, profile declarations: every version they can take is checked against the pin.
  • profile_override, live declarations: live main-jar declarations are walked too, with the same main_jar_declarations scope and management-governs filter.
• A live pin that some combination moves keeps the ref, marked unattested with the existing UnattestedKind::MavenProfileUnpatched. The detail names the profiles and the version they give. This applies to hosted pins and the pre-v5 vendored wiring alike.
• A <profiles> declaration's own ${v} reads its own profile first.

2. Property versions resolved one level deep

${a} with <a>${b}</a> now resolves through every property it names. That includes ${project.version}, which is bound raw (for example ${revision}) and resolved wherever it is read. Both of #2005's views use it:

• version (as the pom spells it): the model, then the declaration's own profile, then the root <properties>.
• build_version: .mvn/maven.config -D user properties first, at every level.

Limits: at most 16 levels, and a cycle, an undefined name or an unterminated ${ never resolves. The version then stays as written, which is never a pin.

One resolver: formats::maven::properties (pure)

• lookup_property / PomLayer: Maven's lookup order. The model comes first, then user properties, then each pom's properties with its active profiles merged in (nearest pom first), then the bare ${version}.
• profile_combinations: the shared enumeration of profile combinations.
• interpolate_strict / interpolate_lenient: one expansion with explicit cycle detection, depth 16, 1024 lookups and 4096 bytes. Strict is for versions. Lenient, for coordinates and model references, keeps an unresolved ${…} visible for may_name.
• read_properties: the <properties> parser.

PomScope and the vendored Reactor::lookup_with / version_override both use this module. Vendoring now weighs the same profile combinations VEX does, where it used to try one profile at a time, and fails closed past the same bound. The old round-based coordinate interpolator and interpolate_each are gone. resolve_in_build takes the interpolation function, so #2026 can reuse it for coordinate alternatives.

Review findings

All 9 are confirmed and fixed. Each behavior finding has a test that failed before 854c3f682.

1. Model references moved by properties (false attestation). Model references are bound raw and resolved with each read's user properties and profiles. So a profile <revision> moves ${project.version} (unattested). A -Drevision=<pin> supplied only by maven.config now makes the spelled and built versions differ, so it is diagnosed, never a ref. Test: model_references_move_with_the_properties_they_are_spelled_through.
2. Attributed or spaced property tags were skipped (false attestation). An element's name now ends at whitespace or /, closing tags may carry whitespace, and <v/> defines an empty value. Tests: profile_properties_with_attributes_are_read and properties::tests::properties_read_attributed_and_spaced_tags.
3. Nested references in a profile value resolved against the root. Each combination is now one merged view. Test: profile_values_resolve_through_their_own_profile.
4. A profile <properties> parse error failed the whole scope. with_user_properties no longer scans profiles, so the hosted rewriter is unaffected. Discovery records the error and withholds only ${…} pins (MovedBy::Unreadable); a literal pin is still attested. Test: unreadable_profile_properties_withhold_only_property_pins, plus a formats assertion.
5. The cross-product budget collapsed multi-profile poms. It is replaced by relevance-filtered combinations, each on its own budget, with a hard bound of 8 combined profiles. Test: many_profiles_that_keep_the_pin_are_attested (5 profiles × a 5-deep chain → attested).
6. The detail reported the lexicographically first alternative. It now names the smallest moving combination's profile ids and the version they give. Test: profile_property_detail_names_the_profile_and_version.
7. Two precedence implementations. Both now use lookup_property and profile_combinations. Test: vendor::jvm::maven_reactor::tests::profiles_that_move_the_version_only_together_are_weighed, which failed before because the planner tried one profile at a time.
8. Two interpolators. There is now one expansion with strict and keep-unresolved modes. Coordinate alternatives are left for Withhold Maven pins whose coordinates a profile redefines #2026.
9. Cleanups. resolutions() drops its from-profile flag (the classifier check derives it), PomScope::fixed and the redundant guard are gone, and readers that never weigh profiles don't scan them.

Two behavior changes come from sharing the resolver:

• The vendored planner now weighs profile combinations and fails closed above 8 relevant profiles.
• Its ${project.*} lookups fall through to user and pom properties when the model has no value, as in Maven.

Tests

Earlier tests:

• profile_properties_redefining_a_pin_property_are_not_attested
• profile_declaration_reads_its_own_profile_properties
• version_property_resolves_through_nested_properties
• vendored_ref_under_profile_properties_is_not_attested
• formats::maven::tests::{version_properties_resolve_recursively_and_fail_closed, profile_properties_give_version_alternatives, interpolation_is_bounded}

Changed expectation after the rebase onto #2005's review fix. In version_property_resolves_through_nested_properties, a pin supplied only by -Dp1=<pin> in maven.config, through a nested property, now expects no attestation. A Socket version that only maven.config supplies is not pom.xml wiring, so it is diagnosed, never a ref.

Runs on 854c3f682:

• cargo test -p socket-patch-core --lib -- vex::discover:: formats::maven vendor::jvm:: passes 726.
• patch::redirect:: together with crawlers::maven passes 953.
• The golden corpus is unchanged (committed_fixture_corpus_matches_golden passes).
• cargo test -p socket-patch-cli --lib vex_sources passes 14.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not done

• Coordinates moved by profile properties are handled in Withhold Maven pins whose coordinates a profile redefines #2026, stacked on this branch.
• Activation is not evaluated. Every profile counts, as in vendored mode.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merge conflict needs a decision (left unmerged, nothing pushed).

This PR now conflicts with its base fix/maven-discovery-false-attestation (#2005) after 9765178 ("Address review: Maven discovery bypass checks match Maven precedence"). Both sides changed the same version-resolution behavior in incompatible ways, in formats/maven/mod.rs (6 hunks), vex/discover/maven.rs (3 hunks) and CLI_CONTRACT.md (2 hunks):

• Stop attesting Maven pins a profile or user property overrides #2005 (base) splits PomDep::version (one-level, root <properties> only — what the hosted rewriter writes and rolls back) from a new build_version (user properties first, project.*/pom.* exempt), and reports a pin that .mvn/maven.config moves under a new UnattestedKind::MavenConfigOverride (vex_maven_config_override). It also narrows profile <dependencyManagement> to "only where management governs the pin" and drops the profile-classifier case from MavenProfileUnpatched (moved to MavenClassifierUnpatched).
• This PR makes PomDep::version the full strict interpolation (user properties, model, own profile, root; 16 deep) with version_text and version_alternatives, adds fixed / profile_properties to PomScope, and folds user-property and profile-property moves into MavenProfileUnpatched.

Question: should this PR be rebuilt on #2005's split — keep version = pom-spelled for the rewriter, put the strict/recursive interpolation into build_version (plus version_alternatives from profile <properties>), keep MavenConfigOverride for .mvn/maven.config moves and use MavenProfileUnpatched only for profile-driven moves? Or should #2005's split be replaced by this PR's single version? Once you choose, the conflict can be resolved mechanically. Since #2026 is stacked on this branch, it may be simpler for the author's own stack tooling to restack it.

---

Generated by Claude Code