Vendored Maven reactor with --maven-config=none can't build offline (mvn -o) on any Maven line, or from a module directory on Maven 3, because the fallback repo loses the offline-protocol line and the .mvn root marker
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
- 68/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Bereich
- build-system
Rechercherichtung
Start in crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs, especially the config_enabled branch at line 229, OFFLINE_LINE at line 27, and REPO_URL at line 32. Run the e2e_vendor_jvm_build::maven_reactor capstone with --maven-config=none on Maven 3.9.11 and 4.0.0-rc-7. Done means the documented none mode either preserves offline and module builds or clearly warns and documents those limitations.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
[agent] Found by the scheduled Maven bug-hunt routine (ledger #318).
Summary
v5 reactor vendoring has two wiring choices. --maven-config=auto (the default) writes .mvn/maven.config with -Daether.offline.protocols=file plus -Dmaven.repo.local.tail=…. --maven-config=none "uses only the fallback file repository": <url>file://${maven.multiModuleProjectDirectory}/.socket/vendor/maven2</url> in the local root pom. The docs recommend none as the workaround for the Maven 3.9.2–3.9.8 -f limitation.
With none, nothing is written under .mvn/, and the fallback repository relies on two things that .mvn/ provided:
- Offline builds break on every tested Maven line. Without
aether.offline.protocols=file,mvn -orefuses thefile://repository:Cannot access socket-patch-vendor (file:///…/.socket/vendor/maven2) in offline mode and the artifact org.apache.commons:commons-text:jar:1.10.0-socket.1d3c1fd2 has not been downloaded from it before.Same checkout, same Maven,automode:mvn -opasses (thee2e_vendor_jvm_buildcapstone). - Module invocations break on Maven 3.9. Without a
.mvn/directory, Maven 3 setsmaven.multiModuleProjectDirectoryto the directory it was started from.cd a && mvn …andmvn -f a/pom.xmlfrom the root then look for the repository undera/.socket/vendor/maven2, which doesn't exist:Could not find artifact org.apache.commons:commons-text:jar:1.10.0-socket.1d3c1fd2. Maven 4.0.0-rc-7 detects the root here and passes.
Both fail loudly, because the suffixed coordinate exists nowhere else, so nothing silently goes unpatched. But a fresh checkout of a none-vendored reactor can't build in the two shapes that auto supports and that the capstone tests: offline, and cd <module>.
Impact
none is the documented escape hatch for Maven 3.9.2–3.9.8 users, and it persists in the ledger ("remains in effect on later runs and repair"). Projects that pick it lose offline / air-gapped builds (vendored mode's selling point: "hermetic, offline-safe installs") and, on Maven 3, per-module builds. Nothing warns about either, and the docs don't mention them.
Repro (Linux, JDK 21)
I used a local copy of the e2e_vendor_jvm_build::maven_reactor capstone, changed only to add --maven-config=none to the vendor call and to skip the .mvn/maven.config assertions:
# reactor: aggregator + corp-parent + a (commons-text 1.10.0 literal) + b; staged agent patch; then
socket-patch vendor --json --offline --maven-config=none # exit 0, applied 1, no .mvn/ written
# fresh checkout (no manifest/blobs), commons-text purged from the local repository:
mvn -o package dependency:build-classpath # FAIL: Cannot access socket-patch-vendor (...) in offline mode
mvn package dependency:build-classpath # ok: module a resolves 1.10.0-socket.1d3c1fd2 (patched)
mvn -f /abs/root/pom.xml ... (from outside the root) # ok
cd a && mvn package dependency:build-classpath # FAIL (3.9.11): Could not find artifact ...:1.10.0-socket.1d3c1fd2
mvn -f a/pom.xml package ... (from the root) # FAIL (3.9.11): same
The unmodified capstone (auto) passes on 3.9.11 and 4.0.0-rc-7, including the offline root build and the offline cd a build.
Expected vs actual
- Expected: per docs/design/maven-vendoring.md, a vendored reactor commits "a local repository so another checkout can build without socket-patch or the Socket service", and
none"uses the fallback file repository only". It is offered as the safe choice for awkward invocation shapes. The scan help describes vendored mode as "hermetic, offline-safe installs". So either thenonewiring keeps offline and module builds working (for example by still writing.mvn/maven.configwith only-Daether.offline.protocols=file, which also gives Maven 3 its root marker), orvendorwarns thatnonegives up offline and module invocations, and the docs say so. - Actual: no warning, nothing in the docs, and
mvn -o/ module builds fail on a fresh checkout.
Matrix (Linux, JDK 21)
| Maven | auto capstone (root, -o, cd a -o) |
none: root online |
none: root -o |
none: cd a / -f a/pom.xml |
none: -f root from outside |
|---|---|---|---|---|---|
| 3.6.3 | blocked (Central 429 during fixture warm-up) | blocked | blocked | blocked | blocked |
| 3.8.8 | blocked (429) | blocked | blocked | blocked | pass |
| 3.9.11 | pass | pass | fail (2/2) | fail (offline in the harness, online by hand, 2/2) | pass |
| 4.0.0-rc-7 | pass | pass | fail (2/2) | pass | pass |
macOS and Windows are untested. The cause is in the generated wiring, not the OS.
Tested on: main 2463257 (#277, the new reactor backend). There is no earlier release to bisect: the backend is new in this commit.
Suspect code
crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs:229:if config_enabled { … }is the only placeOFFLINE_LINE(maven_reactor.rs:27) is written, sononedrops it along with the tail.maven_reactor.rs:32:REPO_URL = "file://${maven.multiModuleProjectDirectory}/.socket/vendor/maven2". On Maven 3 this depends on a.mvn/directory existing at the root, which onlyautocreates.
- Vorherrschende Sprache
- Rust
- Sterne
- 8
- Forks
- 0
- Ø Merge
- 18 Std. 4 Min.
- Gemergte PRs (30 T.)
- 70
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus SocketDev/socket-patch
-
agent:triaged bug bughunt pm:composer priority:p2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
SocketDev/socket-patch#515 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:npm priority:p1
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
SocketDev/socket-patch#464 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:npm priority:p1
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
SocketDev/socket-patch#433 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:uv priority:p1
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
SocketDev/socket-patch#408 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
SocketDev/socket-patch#370 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in SocketDev/socket-patch
Ähnliche Issues
-
discover: `sudo RTK_DISABLED=$VAR …` is not detected as a bypass when `sudo` is a transparent prefixOffenarea:cli bug good first issue priority:medium
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
rtk-ai/rtk#4412 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
skill:code-review
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
component:sight
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
agentic-os-org/ANOLISA#4115 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
rivet-dev/rivet#5819 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
A-io-database bug needs triage python
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
Maintainer antworten meist innerhalb von 1 Tag