Keep the basedir unset for a parent served from the project-local repository

[slachiewicz]

Closes #13211.

After mvn install of a parent, a later build of a child that doesn't include the parent in the reactor gets a MavenProject for that parent with a basedir under .mvn/target/project-local-repo. The ReactorReader serves that directory as WorkspaceRepository, and DefaultProjectBuilder builds every workspace result from its file. Maven 3 leaves the basedir null for a parent outside the reactor, and plugins depend on that to load the parent's attached artifacts instead of its sources (maven-site-plugin's inheritance-interpolation IT, apache/maven-site-plugin#1259).

A workspace result is now built from its file only when the POM belongs to a project of the current session. WorkspaceParentProjectBuilderTest covers both cases through a workspace reader on the test session: a parent served from the project-local repository has no file and no basedir, and a parent that is a project of the session keeps its basedir. The first test fails without the fix.

Verified: maven-site-plugin ITs on a Maven 4.0.0-SNAPSHOT with this change and doxia-sitetools 2.1.0 → 62 passed, 0 failed (without the change, inheritance-interpolation fails). maven-core unit tests → 632 run, 0 failures.

[gnodet-bot]

The fix is correct. The isProjectPom check properly distinguishes reactor-member POMs (which have a real basedir) from POMs served by the workspace out of .mvn/target/project-local-repo (which should be treated as repository artifacts, not local projects).

A few observations on the implementation:

• projects == null guard — despite the @Nonnull annotation on Session.getProjects(), the implementation in DefaultSession.getProjects(List) propagates a null from MavenSession.getProjects() during session bootstrap (before the reactor is fully wired). The null check is valid.
• filter(Objects::nonNull) — DefaultSession.getProject(MavenProject) returns null for projects whose basedir is null, so the list returned by getProjects() can indeed contain nulls. The filter is correct and necessary.
• Path comparison — toAbsolutePath().normalize() is sufficient for the purpose here (matching POMs the session already knows about). toRealPath() would resolve symlinks but would require IOException handling for no practical gain in Maven's usage.
• No unit test — the PR verifies the fix via external maven-site-plugin ITs (inheritance-interpolation). A unit test in DefaultProjectBuilderTest that exercises the localProject flag for a workspace-resolved parent that is not a reactor member would provide cheaper regression protection. Consider adding one.
• Milestone — none is set; this targets maven-4.0.x with the bug label, so milestone 4.0.0-rc-7 seems appropriate.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[gnodet-bot]

Re-review after the second commit (cddc4b75) which adds the unit tests.

Previous finding addressed: The prior review noted the absence of a unit test. WorkspaceParentProjectBuilderTest directly covers both cases:

• parentFromProjectLocalRepositoryHasNoBasedir — workspace reader serves a POM from .mvn/target/project-local-repo; the session's reactor does not include it → file and basedir are null ✓
• parentOfTheSessionKeepsItsBasedir — workspace reader serves the same POM that is a reactor project → file and basedir are set ✓

The getWorkspaceReader() hook in AbstractCoreMavenComponentTestCase is clean: it returns null by default (no workspace reader for existing tests — setWorkspaceReader(null) is safe in the resolver API), and subclasses override it. Both test cases correctly exercise the isProjectPom path introduced by the fix.

No new concerns with this commit. The PR is solid.

This review was generated by an AI agent, Hermès on behalf of @gnodet.