hboutemy commented on PR #1259:
URL:
https://github.com/apache/maven-site-plugin/pull/1259#issuecomment-4640278375
Analysis done with AI:
## Why `inheritance-interpolation` IT fails with Maven 4 but passes with
Maven 3
### Root cause: Maven 4's `project-local-repo`
Maven 4 introduces a **session-scoped `project-local-repo`**
(`target/project-local-repo/`) — a flat repository (groupId as dots, not
slashes) that stores consumer POMs for all projects involved in the build,
including non-reactor parents.
During Maven 4's reactor initialization, when resolving `relative-parent`
(via `relativePath`) and then its parent `repo-parent` (from the local repo),
Maven 4 **creates a `project-local-repo` entry for `repo-parent`** and sets
`MavenProject.getBasedir()` to that project-local-repo directory:
```
target/project-local-repo/org.apache.maven.plugins.site.its.inheritance-interpolation/repo-parent/1.0-SNAPSHOT/
```
### How this breaks doxia-sitetools
In `DefaultSiteTool.getSiteModel()`, the site descriptor lookup path is
chosen based on `project.getBasedir()`:
```java
if (project.getBasedir() == null) {
// POM is in the repository: resolve site descriptor as artifact
siteDescriptor = getSiteDescriptorFromRepository(project, repoSession,
...);
} else {
// POM is in build directory: look for site descriptor as local file
siteDescriptor = getSiteDescriptor(siteDirectory, locale); // looks for
src/site/site.xml
}
```
| | `repo-parent.getBasedir()` | Code path taken | Result |
|---|---|---|---|
| Maven 3 | `null` | repository artifact lookup | finds
`repo-parent-1.0-SNAPSHOT-site.xml` in `target/local-repo/` ✅ |
| Maven 4 | `target/project-local-repo/.../repo-parent/1.0-SNAPSHOT/` |
filesystem lookup | looks for `.../src/site/site.xml` — not found ❌ |
The `site.xml` **was** present in `project-local-repo/` as
`repo-parent-1.0-SNAPSHOT-site.xml` (the build log shows it gets deleted at the
end of the build by the root reactor's `clean` phase), but the artifact-based
resolution is never attempted — the code only looks for `src/site/site.xml`
under the basedir.
This is confirmed by the build log: `[DEBUG] No parent level 3 site
descriptor` appears immediately after `[DEBUG] Looking for site descriptor of
level 3 parent project: repo-parent`, with no artifact resolution attempt in
between.
### Cascade of effects
Since `repo-parent`'s `site.xml` is never read, the entire parent chain
returns null site models. `getSiteModel()` falls back to **`default-site.xml`**:
```xml
<bannerLeft name="${project.name}" />
```
Late interpolation resolves `${project.name}` to just `child` because Maven
4 no longer inherits `<name>` from parent POMs (consumer POMs do not propagate
the `<name>` template), so `project.name` defaults to the artifactId.
### Expected vs actual
| Check | Expected (Maven 3) | Actual (Maven 4) |
|---|---|---|
| `bannerLeft` name for `child` | `bannerLeft project.artifactId = child` |
`child` |
| `bannerLeft` name for `reactor-parent` | `bannerLeft project.artifactId =
reactor-parent` | `reactor-parent` |
| Source of site model | `repo-parent/src/site/site.xml` (via repository
lookup) | `default-site.xml` (fallback) |
### Where to fix
The issue is in **doxia-sitetools** `DefaultSiteTool.getSiteModel()`: when
`project.getBasedir() != null` but the filesystem lookup finds no site
descriptor, it should fall back to the artifact-based repository lookup. That
would correctly handle Maven 4's project-local-repo case, where a non-reactor
parent has a non-null basedir pointing to a repository directory rather than a
real source tree.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
