Jeremy Landis created MSITE-948:
-----------------------------------
Summary: Site stage/deploy should respect
'child.site.url.inherit.append.path="false"' and not use relativePath related
to that parent
Key: MSITE-948
URL: https://issues.apache.org/jira/browse/MSITE-948
Project: Maven Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 4.0.0-M7, 3.12.1
Reporter: Jeremy Landis
All versions of maven have long been affected by this and there are many
tickets opened / closed claiming to have resolved or seem to be outstanding for
years with no resolution. I believe they are mostly related.
The 'child.site.url.inherit.append.path="false"' was added back in maven 3.6.0
with claim to stop this behaviour but its never worked outside of effective pom
looks right IMO. At least most platforms support that now (artifactory was
late in that game).
Currently regardless of that setting, the maven site plugin doesn't respect it
or even look at it from what I can tell. Its there in the debug tree but the
code doesn't appear to look at that to determine what it will do with
relativePath.
So, if I have project example [https://github.com/hazendaz/base-parent] and I
happen to have those set (such as
[https://github.com/hazendaz/base-parent/commit/58e9f8a7749a80e74e8197d5b90b17458cadb161]),
then anything downstream using that parent which is unrelated I would expect
to adhere to the request and not attempt to use the super pom for its
calculations at all. But it does not do so.
I suspect areas of code problematic are getTopLevelProject(MavenProject) or
'getDeployModuleDirectory'. The later being where it matters with
'relativePath' determined.
The main issue is with multi module downstream projects. Fixing this issue I
suspect would have immediate impact on being able to use the site plugin
directly and not need scm publish. Scm publish tends to work for single module
but it still suffers from fact that the site plugin messes up the data before
it ever gets there.
For example, if my project is 'somerepo.git', I would expect site:stage to put
the data in 'target/staging' as the documentation states it will do so. It
however does not, regardless of the above noted setting. What it does instead
is determine that it needs the relative path to be '../somerepo.git' just
because it has a parent pom from some other project from same hosted platform
(gh-pages on github). So the staging then puts that in 'target/somerepo.git'
instead. So maven scm publish cannot even see that. The site deploy fails to
do it correctly as it completely changes out the repo to deploy to and tries to
go to the parent which in most cases like this isn't related at all. My base
super pom for example is used by quite a number of repos and they all have
issues with site distributions as a result.
So how can we make the site plugin actually respect
'child.site.url.inherit.append.path="false"'? Or any way to actually make that
easier like configure it to just stop doing that logic as unnecessary. The pom
settings IMO are over bearing as it is so a config option would be far better
and easier to implement.
I've debugged this far enough to just keep changing the site plugins
determination on the relativePath to be './' which fixes the issue. Note: The
rest of relative path for multi module is needed but starting part was wrong
'../' vs './'.
IMO I don't think maven should even be touching items like this, its so hard to
understand the math as a result. Thus why so many tickets get opened for same
thing in various different ways. Over the years we have tried just about
everything to make this work and honestly the only thing that really does
currently is to drop maven from doing the site distribution entirely and use
gh-actions to do the same or other solutions on different platforms. It would
be better IMO to use maven site plugin directly and/or with scm publish if it
consistently worked as documented. Maybe a flag isn't even need, maybe just
fixing maven site plugin to stop going outside of the staging folder would be a
good step 1 as scm publish should be ok then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
