fix(maven): detect projects below workspace root

[Mucheen]

Closes #26

Summary

• discover a Maven project from visible pom.xml paths when the opened workspace is a parent directory
• try candidates by depth and lexical order, continuing past malformed POMs so a valid nested project can still be selected
• convert nested Maven module identifiers to workspace-relative paths for Rust scanning, then restore Maven-root-relative paths in the Swift UI model
• use the nested Maven root for the Maven panel, framework run configurations, toolchain metadata, launch working directory, and wrapper resolution
• construct multi-segment file URLs without percent-encoding path separators
• include the macOS Swift concurrency fix required by the updated preview/0.2.0 base
• document the shared Maven and Java run-configuration contracts and add Rust/Swift regression coverage

Affected modules

• Rust Maven discovery and run-configuration generation
• Swift Rust bridge, Maven operations, and executable resolution
• shared Rust Core API contract
• macOS pointer cursor concurrency annotation

Validation

• ./scripts/verify-rust-core.sh - passed, including Rust formatting, 156 Rust Core unit tests, 5 Git worktree integration tests, workspace Rust tests, Swift application build, C ABI bridge checks, and linked-symbol checks
• ./scripts/verify-service-boundaries.sh - passed
• ./scripts/verify-shared-contracts.sh - passed
• ./scripts/verify-windows-boundaries.sh - passed
• git diff --check - passed

Local environment limitation

• Full ./scripts/test-macos.sh cannot run with the installed Command Line Tools because its Swift toolchain does not provide the Testing module. GitHub macOS CI uses Swift 6.2 and is the final Swift test verification.

Focused review

• malformed shallow POM fallback and deterministic candidate ordering
• workspace-relative versus Maven-root-relative module path conversion
• multi-component file URL construction for nested Maven roots

Latest base synchronization

• merged preview/0.2.0 at 58e7583f and resolved the run-configuration conflicts by preserving nested Maven-root handling together with nested-worktree filtering and Java configuration deduplication
• reran ./scripts/verify-rust-core.sh, ./scripts/verify-service-boundaries.sh, ./scripts/verify-shared-contracts.sh, and ./scripts/verify-windows-boundaries.sh; all passed
• ./scripts/test-macos.sh remains locally blocked because the installed Command Line Tools do not provide the Swift Testing module; ./scripts/verify-core.sh remains blocked by its existing reference to removed Sources/Lithe/Core/Terminal/TerminalBuffer.swift. GitHub Swift 6.2 CI provides final macOS verification.

[xiaoyumuxi]

需要确认的问题

1. [重要·待验证] Swift 侧用 appendingPathComponent 拼接多段相对路径，可能被 %2F 编码
   两处：
   // RustCoreBridge.swift — makeProject
   let rootURL = relativePath == "."
   ? workspaceRootURL
   : workspaceRootURL.appendingPathComponent(relativePath, isDirectory: true)

// RunExecutableResolver.swift
let toolchainProjectURL = id == "project-maven" && plan.workingDirectory != "."
? projectURL.appendingPathComponent(plan.workingDirectory, isDirectory: true)
: projectURL
​
relativePath / workingDirectory 是多段路径（如 "services/api"、"projects/demo"）。appendingPathComponent 的语义是"单个路径组件"，对参数里的 / 会做 percent-encoding（追加 a/b 得到 a%2Fb），这和 appending(path:)（macOS 13+，路径语义）不同。虽然 file URL 的 %2F 在 .path 解码时恰好能还原，实际文件访问可能"碰巧能用"，但会带来两个隐患：
URL 相等性断裂：和文件监听器等用 URL(fileURLWithPath:) 正常构造的 URL 比较时不相等；
显示/日志异常：UI 上可能出现 services%2Fapi。
更关键的是：新增测试掩盖了这个问题。 mavenScanPayloadDecodesRustCamelCaseIdentifiers 和 mavenToolchainResolvesTheWrapperFromTheLaunchWorkingDirectory 的期望值也是用同一个 appendingPathComponent 构造的，两边编码一致所以必然相等，编码错了也测不出来。建议：
改为逐段拼接（split(separator: "/") 后逐个 append）或使用 appending(path:directoryHint:)；
测试期望值改用 URL(fileURLWithPath: root.path + "/services/api") 这类独立构造方式，才能真正断言 URL 正确。

可以参考这个解决方案，在本地跑：swift -e 'import Foundation; print(URL(fileURLWithPath:"/w").appendingPathComponent("services/api", isDirectory: true).absoluteString)'
​
输出是 file:///w/services/api 就没问题；是 file:///w/services%2Fapi 就坐实了，如果这种方案的话那么就需要贴截图来认证了

其他建议，可后续修复

2. 模块在选中 Maven root 之外时静默退化为错误路径
   maven_module_path 中，若推断出的模块路径不以 maven root 为前缀（多 reactor 工作区里，某个 Java 文件最近的 pom 属于另一个项目），strip_prefix 失败后保留原 workspace 相对路径，但 cwd 是 maven root —— -pl 参数会指向错误模块。单 reactor 限制已在文档中声明，可以理解，但建议这种情况至少发一个 diagnostic，而不是静默生成跑不起来的配置。
3. RunExecutableResolver 硬编码 "project-maven" 字符串
   toolchain id 是 shared contract 里的约定值，在解析器里裸写字符串比较有点漏抽象，建议提常量或按 toolchain kind 判断。
4. mvnw.cmd 处理不一致
   generate() 里 has_maven_project 新增了 mvnw.cmd 检查（好），但 detect_requirements 里 wrapper 检测仍只看 mvnw。Windows 下有 cmd 无 sh 脚本的项目会检测到 Maven 但拿不到 wrapper。属历史遗留，可顺手统一。

[1lck]

有冲突解决一下哈
@Mucheen

[Mucheen]

好的，晚一点哈

…

---Original--- From: ***@***.***> Date: Thu, Aug 13, 2026 13:39 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [1lck/Lithe-IDEA] fix(maven): detect projects below workspace root (PR #64) 1lck left a comment (1lck/Lithe-IDEA#64) 有冲突解决一下哈 @Mucheen — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[1lck]

Reviewed against main: Maven nested-root selection, workspace-relative path conversion, run configuration handling, contracts, and regression coverage are consistent. CI passed.