Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning

Offen
  • Stimmt etwas nicht?
#459 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
65/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
build-system, devtools

Rechercherichtung

Start in crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs at lines 711-742, 930-948, and 1020-1036, then run the e2e_vendor_jvm_build harness with the profile-based reactor from the issue. Trace how profile properties are resolved and how overridden declarations are handled. Done means the profile-driven version is not silently rewritten or pinned, and the expected conflict warning is produced.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:triaged bug bughunt pm:maven priority:p3

[agent] Found by the scheduled Maven bug-hunt routine (ledger #318).

Summary

The v5 Maven reactor backend (vendor, scan/get --mode vendored) resolves ${property} dependency versions from top-level <properties> only (maven_reactor.rs:711: "Top-level <properties> (profiles excluded)"). Suppose a module declares <version>${ct.version}</version>, the parent sets ct.version=1.10.0, and an active profile (activeByDefault, <jdk>[11,)</jdk>, a property activation…) overrides it to 1.11.0. Maven builds 1.11.0. The planner instead sees 1.10.0, matches the patch base, and replaces ${ct.version} with the literal 1.10.0-socket.<hex8>. It also adds a dependency-management pin in the local root.

After vendoring, the build silently moves from commons-text 1.11.0 down to 1.10.0-socket.1d3c1fd2. vendor exits 0 with applied: 1 and gives no warning about the profile, and VEX then attests not_affected for 1.10.0.

Impact

  • vendoring silently changes the version a profile-driven build links, here a downgrade. Profile-switched library versions (by JDK or by an activation property) are a common pattern.
  • The profile's override goes dead because the literal replaces the ${ct.version} reference.
  • The equivalent non-profile case is already handled. When a module overrides the inherited property in its own top-level <properties>, the planner emits conflicting_literal_version and leaves the root unpinned (inherited_property_overridden_by_a_module_is_left_alone). The profile variant takes the silent path instead.

Expected vs actual

  • Expected (docs/design/maven-vendoring.md, "Maven"): "Rewrites of conflicting base-version literals and resolved local properties, including profiles … conflicting explicit versions … produce specific warnings; the backend does not silently claim those unsupported declarations are patched." A property that an active, or possibly active, profile resolves to something other than the patch base should be treated like the module-override case: warn conflicting_literal_version (or a profile-specific code) and leave the declaration alone. The planner shouldn't rewrite it to the suffixed base.
  • Actual: ${ct.version} is rewritten to 1.10.0-socket.1d3c1fd2 and the local root gets a pin. Exit 0, no warning, and the build resolves the suffixed 1.10.0 instead of 1.11.0.

Repro

Reactor (aggregator → corp-parent, a):

<!-- corp-parent/pom.xml -->
<properties><ct.version>1.10.0</ct.version></properties>

<!-- a/pom.xml (parent = corp-parent) -->
<profiles>
  <profile>
    <id>modern-jdk</id>
    <activation><activeByDefault>true</activeByDefault></activation>   <!-- or <jdk>[11,)</jdk> -->
    <properties><ct.version>1.11.0</ct.version></properties>
  </profile>
</profiles>
<dependencies>
  <dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-text</artifactId>
    <version>${ct.version}</version>
  </dependency>
</dependencies>

Steps: the repo's e2e_vendor_jvm_build harness (prebuilt patch-service mock, staged manifest for pkg:maven/org.apache.commons/[email protected]), with this reactor in place of write_reactor:

mvn package dependency:3.5.0:build-classpath -Dmdep.outputFile=target/cp.txt
#  a → ~/.m2/.../commons-text/1.11.0/commons-text-1.11.0.jar
socket-patch vendor --json --offline
#  exit 0, status success, applied 1; only maven_f_outside_root / maven_mirror_of_all degraded notes
#  a/pom.xml:          <version>${ct.version}</version>  →  <version>1.10.0-socket.1d3c1fd2</version>
#  corp-parent/pom.xml: + dependencyManagement pin 1.10.0-socket.1d3c1fd2 + socket-patch-vendor repo
mvn package dependency:3.5.0:build-classpath -Dmdep.outputFile=target/cp.txt
#  a → .socket/vendor/maven2/.../1.10.0-socket.1d3c1fd2/commons-text-1.10.0-socket.1d3c1fd2.jar
socket-patch vex --offline -O vex.json
#  exit 0, [email protected] not_affected

OS × version

OS Maven JDK Activation Result
Linux 3.9.11 21 <jdk>[11,)</jdk> reproduces (silent 1.11.0 → 1.10.0-socket)
Linux 3.9.11 21 activeByDefault reproduces
Linux 4.0.0-rc-7 21 activeByDefault reproduces
Linux 3.6.3 / 3.8.8 21 – blocked (Maven Central 429 during fixture warm-up)
macOS / Windows – – – untested. The planner is pure text logic, so no OS dependence is expected

Tested on main 2463257 (v5 consolidation #277). This isn't a regression: the reactor backend is new in v5.

Suspect code

  • crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs:711-742: Pom::parse collects only project/properties.
  • crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs:930-948: Reactor::lookup never consults profile properties.
  • crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs:1020-1036: the overridden check only looks at inheritors' top-level properties, so a profile override in the declaring pom, or in any pom on its chain, doesn't trip it.

A possible fix: when any profile on the chain (including the declaring pom) defines the property with a value that isn't base-like, take the conflicting_literal_version path, because activation can't be evaluated statically.

Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
18 Std. 4 Min.
Gemergte PRs (30 T.)
70

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.