Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support owner-aware toolchain requirements for multiple Maven reactors

Đang mở
  • Có gì không ổn?
#285 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, rust
Lĩnh vực
build-system, devtools, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
TypeScript
Star
1.8k
Fork
151
Merge trung bình
7 giờ 51 phút
Pull request đã merge (30 ngày)
351

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của 1lck/Lithe-IDEA

Tất cả issue của 1lck/Lithe-IDEA

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.