fix(maven): guard missing project index before auto-unbox

[shoemoney]

Fixes auto-unbox NPE in MojoExecutor when forked execution references a missing project.

Bug: projectIndex.getIndices().get(projectId) returns null for an unknown projectId, then int index = ... auto-unboxes null to NPE at MojoExecutor.java:441. Similarly getProjects().get(projectId) can return null, leading to NPE on clone.

Root cause: In parallel builds (-T), the projects map in ProjectIndex is read and written concurrently through the same cached instance. Plain HashMap is not thread-safe for concurrent read/write, so it can appear to be missing a key that is actually present. Extensions that modify session projects can also cause a lookup to fail legitimately.

Fix:

• Changed the projects map in ProjectIndex from HashMap to ConcurrentHashMap so concurrent access in parallel builds no longer corrupts it.
• Added null guards in MojoExecutor.executeForkedExecutions() before the auto-unbox, throwing a LifecycleExecutionException with a message noting parallel builds and extensions modifying session projects as likely causes.

Evidence: Verified with mvn -pl impl/maven-core -am compile -Dspotless.check.skip=true -o, which returns BUILD SUCCESS. Branch verified against upstream/master.

[gnodet]

Nice fix — clean, minimal, and correct.

What this does well:

• Replaces an opaque auto-unbox NullPointerException with a descriptive LifecycleExecutionException
• Guards both the indices and projects lookups (they're populated together in ProjectIndex constructor, but can diverge under concurrent HashMap mutation in parallel builds)
• The Integer idx → int index = idx pattern makes the null-safety guarantee local and compiler-enforced — good
• Scope is appropriately narrow — doesn't try to fix the underlying HashMap thread-safety in ProjectIndex, which would be a separate, larger change

Minor suggestion (non-blocking): The error messages could mention the likely causes, to help users self-diagnose:

"No project index found for project " + projectId
    + ". This can happen with parallel builds (-T) or when extensions modify the session projects."

Without the hint, users will just see "No project index found" and file another issue asking why. But this is a nice-to-have, not a blocker.

CI: Pending at time of review — please verify green before merge.

[gnodet]

Thanks for the fix — the null guards are a clear improvement over the opaque NPE. One thing worth addressing in this PR though:

Root cause: HashMap corruption under parallel builds (-T)

The most likely real-world trigger for this NPE is concurrent access to the projects map in ProjectIndex. In MojoExecutor.executeForkedExecutions(), the projects map is both read (.get() at line 443) and written (.put() at lines 460, 472) — and in parallel builds, multiple threads do this concurrently through the same cached ProjectIndex instance.

Plain HashMap is not thread-safe for concurrent read/write. The internal structure can silently corrupt (especially during resize), causing .get() to return null for a key that is in the map. In that scenario, the projectId is valid and present — it's the HashMap corruption that makes it appear missing.

With only the null guards, the build still fails in this case — just with a better message. But it shouldn't fail at all.

Suggested additional change

In ProjectIndex.java, change the projects map from HashMap to ConcurrentHashMap:

public ProjectIndex(List<MavenProject> projects) {
    this.projects = new ConcurrentHashMap<>(projects.size() * 2);
    this.indices = new HashMap<>(projects.size() * 2);  // read-only after construction, safe as-is
    ...
}

The indices map can stay as HashMap — it's never written to after construction, so it's safe for concurrent reads.

This way:

• Parallel builds: ConcurrentHashMap prevents the corruption → build succeeds (root cause fixed)
• Stale cached index / extensions: the null guards in MojoExecutor catch genuinely missing keys → clear error (your fix)

Both changes together give a complete fix. What do you think?

[gnodet]

I think it would be better to fix the main cause at the same time.

[shoemoney]

Done, switched ProjectIndex to ConcurrentHashMap and added the parallel-build/extension hint to the error messages in f892d1c.

[gnodet]

Updated review after the second commit (f892d1c):

The ConcurrentHashMap change in ProjectIndex is the key addition — it fixes the root cause for parallel builds (-T), where the previous HashMap could silently corrupt under concurrent read/write, making .get() return null for keys that are present. With this change, the build actually succeeds in that scenario instead of just failing with a better message.

Note: the indices null guard (first commit) already overlaps with #12911 which was merged earlier today. The remaining value of this PR is:

1. ConcurrentHashMap in ProjectIndex — the root cause fix (not in #12911)
2. forkedProject null guard — defense-in-depth (not in #12911)
3. Enriched error messages — mention parallel builds / extensions as causes

CI is running on the latest push — once green, this looks good to merge.

[shoemoney]

Thanks for the review and the approval, @gnodet — and good catch on the #12911 overlap.

CI was red on MojoExecutorForkedExecutionTest.executeForkedExecutionsThrowsDescriptiveExceptionForUnknownProject: the test that landed with #12911 asserts the message contains not in the reactor, and my rewritten messages had dropped that phrase. Pushed 9057215 to restore the original wording and append the parallel-build / extension context to it rather than replacing it, so both the assertion and the enriched diagnostics hold.

Verified locally on maven-core: 620 tests, 0 failures (was 1), Checkstyle 0 violations, Spotless clean.

(The CI run for 9057215 is sitting in action_required — it needs a committer to approve the workflow run before it can go green. No rush from my side, just flagging it so it isn't waiting silently.)

[shoemoney]

CI is green on 9057215 — 22/22 checks passing (full-build and integration-tests across ubuntu/macos/windows on 17, 21, 25). That was the last thing you were waiting on, @gnodet.