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

Support owner-aware toolchain requirements for multiple Maven reactors

未关闭
  • 哪里不对？
#285 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
java, rust
领域
build-system, devtools, tooling

调研方向

Start by reading PR #274 and the shared toolchain requirements contract, then trace Rust Core requirement generation from each launch plan's reactor cwd. Add regression fixtures for Java 17/21 reactors, conflicting vendors, wrapper versions, and standalone Java entries; run Rust Core focused/full verification plus the Windows and macOS boundary tests.

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

描述

area:maven enhancement review: high

Context

PR #274 makes Java run configurations resolve Maven ownership per source entry. This correctly keeps independent nested reactors on separate cwd and module selectors. Toolchain requirements are still generated from one workspace-level Maven root, however, so configuration ownership and requirement ownership can disagree.

This is broader than #272, which is about recognizing and launching a Java entry point from a nested Maven reactor, and should be handled as a separate follow-up.

Problem

Given one opened workspace containing:

services/alpha/pom.xml  # requires Java 17
services/beta/pom.xml   # requires Java 21

Core can generate an alpha configuration owned by services/alpha and a beta configuration owned by services/beta. If requirement detection selects alpha as the single Maven root, .lithe/toolchains/requirements.json may still declare project-jdk.minimumVersion = 17. Beta then binds the same project-jdk and can be launched with an incompatible JDK.

The same mismatch applies to vendor preferences and Maven wrapper/version metadata: a workspace-level value must not silently describe only one reactor.

Recommended design

Treat Maven owner roots as an explicit input to requirement generation instead of rediscovering one global root.

  1. Aggregate constraints that are safely compatible at workspace scope.
    • Set the shared project-jdk.minimumVersion to the highest minimum required by any owned reactor.
    • Keep deterministic ordering so request path order cannot change the result.
    • Preserve existing single-reactor output.
  2. Do not publish a false global constraint when values cannot be merged.
    • Emit preferredVendor only when reactor declarations are compatible; otherwise omit it and surface an actionable diagnostic if needed.
    • Resolve Maven wrappers from each launch plan's reactor cwd, as both platform adapters already do.
    • Emit global Maven wrapper/version metadata only when every relevant reactor can be represented by the same reactor-relative value.
  3. Introduce reactor-scoped toolchain identities only for genuinely incompatible requirements.
    • If the product must support different mandatory JDK vendors or versions per reactor, extend the shared schema and configuration bindings with stable workspace-relative reactor ownership.
    • Update Rust Core, macOS, Windows, shared contracts, persistence migration, diagnostics, and toolchain-selection UX together rather than encoding reactor paths ad hoc in one platform.

The first two steps should solve the Java 17/21 case without multiplying toolchain IDs. The third step should remain conditional on a real requirement that one shared compatible JDK cannot satisfy.

Acceptance criteria

  • A regression fixture with alpha requiring Java 17 and beta requiring Java 21 produces a deterministic Java 21 workspace minimum regardless of request order.
  • Conflicting vendor declarations do not become a misleading workspace-level preference.
  • Different reactor-local Maven wrappers are selected from each configuration's cwd; incompatible wrapper versions are not collapsed into one global version.
  • A single-reactor project keeps its current requirement document and launch behavior.
  • Standalone Java entries in a mixed workspace remain JDK-backed and do not acquire Maven requirements.
  • Shared contract documentation and fixtures describe aggregation and conflict behavior.
  • Rust Core focused/full verification and Windows/macOS boundary tests pass.

Related

  • #272
  • #274
主要语言
TypeScript
星标
1.8k
派生
151
平均合并
7 小时 51 分钟
30 天内合并 PR
351

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

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

1lck/Lithe-IDEA 的其他 Issue

查看 1lck/Lithe-IDEA 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

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