Am 2021-08-16 um 18:13 schrieb Michael Osipov:
Am 2021-08-16 um 16:51 schrieb Michael Osipov:
Am 2021-08-16 um 13:26 schrieb Slawomir Jaranowski:
Hi,
Maven site parent descriptor is not resolved by maven 3.8.2.
Without changing in project, build on maven 3.8.1, I have in logs:
[INFO] Rendering site with default locale English (en)
[DEBUG] Computing decoration model of
org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT for
locale en
[DEBUG] Reading site descriptor from
.../sign-maven-plugin/src/site/site.xml
[DEBUG] Looking for site descriptor of level 1 parent project:
org.simplify4u:parent:pom:2.13.0
[DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0
for
locale en, trying without locale...
[DEBUG] Reading parent level 1 site descriptor from
.../org/simplify4u/parent/2.13.0/parent-2.13.0-site.xml
[INFO] Rendering content with
org.apache.maven.skins:maven-fluido-skin:jar:1.9 skin.
And with maven 3.8.2
[INFO] Rendering site with default locale English (en)
[DEBUG] Computing decoration model of
org.simplify4u.plugins:sign-maven-plugin:maven-plugin:0.3.2-SNAPSHOT for
locale en
[DEBUG] Reading site descriptor from
.../sign-maven-plugin/src/site/site.xml
[DEBUG] Looking for site descriptor of level 1 parent project:
org.simplify4u:parent:pom:2.13.0
[DEBUG] No parent level 1 site descriptor.
[INFO] Rendering content with
org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
Only one difference I see in logs is that in maven 3.8.2 I don't have:
[DEBUG] No site descriptor found for org.simplify4u:parent:pom:2.13.0
for
locale en, trying without locale...
Does anybody confirm this behavior?
What else can I check?
Hi Slawek,
the above is an ugliness existing in Doxia for a long time
(MSITE-639). I don't understand how it is related to this new release.
I will try to build the site of the project and get back to you.
If you think you could bisect down to the issue that would be awesome!
Found it:
mosipov@mikaw10 MINGW64 /d/Entwicklung/Projekte/maven
((5a8997312...)|BISECTING)
$ git bisect bad
5a8997312680a4b9c69a129801524691bc546c08 is the first bad commit
commit 5a8997312680a4b9c69a129801524691bc546c08
Author: Mickael Istria <mist...@redhat.com>
Date: Fri Jun 11 11:55:09 2021 +0200
[MNG-7170] Allow to associate pomFile/${basedir} with
DefaultProjectBuilder.build(ModelSource, ...)
Actually a subset backport of MNG-5669
(5cdb8332f99a36e5a1da202da43e3c7dfbb49322)
Also-By: rfscholte <rfscho...@apache.org>
This closes #478
:040000 040000 e34147123e781aeba66f4d1ae25519a56b1fa7de
afaae4ffe359ab5a6d9fee8b3e3574166ae82675 M maven-core
:040000 040000 4efdf35d4520af3b98d14f789a8369968afab1b8
835f107ac922ca4099277f7c9e9cefb4ca3550d3 M maven-model-builder
Try branch maven-3.8.x-revert-MNG-7170 or
http://home.apache.org/~michaelo/apache-maven-3.8.x-revert-MNG-7170-bin.tar.gz.
We need now to engage with Mickael Istria to figure to whether the
appraoch is incorrect or really a bug in Doxia. A similar finding is here:
https://github.com/eclipse-ee4j/eclipselink/issues/1242
Please report a JIRA issue.
I was able to track down the issue in Doxia Sitetools. See this
screenshot [1]. With the change of MNG-7170 it assumed that the parent
is part of the reactor since the POM file path is set. It obviously isn't.
There are now two sides of the medal. To solve this properly one likely
need to modify/tighten Maven's behavior.
Side 1: If the model comes from a model source, why shouldn't it have a
POM file set? It is available locally. MavenProject#setFile() assumes
that the presence of a POM file indicates that this is a reactor project
module and has a basedir. Should MNG-7170 have really used
MavenProject#setPomFile() in DefaultProjectBulder?
Side 2: Why should the presence of a POM file imply that this project is
part of the reactor? Is MavenProject#setFile() making too many assumptions?
We'll need to revert this on master and 3.8.x until we have a better
understanding of it.
M
[1] http://home.apache.org/~michaelo/3.8.2.png
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
