Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support owner-aware toolchain requirements for multiple Maven reactors

Open
  • Is something wrong?
#285 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java, rust
Domain
build-system, devtools, tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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
Dominant language
TypeScript
Stars
1.8k
Forks
151
Avg merge
7h 51m
Merged PRs (30d)
351

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from 1lck/Lithe-IDEA

All issues in 1lck/Lithe-IDEA

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.