Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#430 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
68/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
java, rust
领域
build-system

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

agent:triaged bug bughunt pm:maven priority:p3

[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:

  1. Offline builds break on every tested Maven line. Without aether.offline.protocols=file, mvn -o refuses the file:// 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, auto mode: mvn -o passes (the e2e_vendor_jvm_build capstone).
  2. Module invocations break on Maven 3.9. Without a .mvn/ directory, Maven 3 sets maven.multiModuleProjectDirectory to the directory it was started from. cd a && mvn … and mvn -f a/pom.xml from the root then look for the repository under a/.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 the none wiring keeps offline and module builds working (for example by still writing .mvn/maven.config with only -Daether.offline.protocols=file, which also gives Maven 3 its root marker), or vendor warns that none gives 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 place OFFLINE_LINE (maven_reactor.rs:27) is written, so none drops 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 only auto creates.
主要语言
Rust
星标
8
派生
0
平均合并
1 天 31 分钟
30 天内合并 PR
151

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

SocketDev/socket-patch 的其他 Issue

查看 SocketDev/socket-patch 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。