[
https://issues.apache.org/jira/browse/MSITE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711302#comment-17711302
]
Jeremy Landis commented on MSITE-948:
-------------------------------------
Testing is using 4.0.0-M7 site plugin with fluido 2.0.0-M5 along with scm
publish 3.2.1. Combination doesn't much matter, its been a problem for a very
long time. Short problem is simply that it keeps trying to stage artifacts out
of the 'target/staging' folder one directory up. Reason is simple, its
miscalculates parent that should not be used for such purposes as both hosted
on same site (using github or bitbucket, doesn't matter what git tooling) and
since host matches except for project key it determines to go up one directly
which results in the issues faced. Easiest possible fix IMO would be to simply
prevent it from jumping out of the 'target/staging' folder like that. The
folder it ends up using is named after the git repo such as 'target/repo.git'.
Possible a simple check could resolve that. Will be continuing debugging to
see what adjustments can be made to find a possible easy solution.
> 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: 3.12.1, 4.0.0-M7
> Reporter: Jeremy Landis
> Priority: Major
>
> 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)
