[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622767#comment-17622767
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
nielsbasjes commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288063561
@gnodet Thanks for the code pointer. This really helps in my understanding
the code.
> For the per-project settings.xml, I don't think they should use the
topdir, at least not using the parent hierarchy. I think the way the
multiModelDirectory is currently computed would better fit the need. Especially
if the settings.xml is to be located in the .mvnd/ directory.
I disagree with this because if you want the settings.xml in a `.mvnd` then
you currently must also create a `.mvn` with a dummy file or it will not find
the correct directory.
Also the absense of a `.mvn` in a project can lead to unexpected effects.
@michael-o Yes, good point.
I agree with the property being immutable from an as early moment in the
build as possible.
My current thoughts about the meaning of the topdir:
- It is the `filesystem directory` of the top module `within` the project.
So I intend to walk up the `project/module tree` instead of the `filesystem
directory tree`.
- Walking up stops if there is no parent defined or the parent is outside
the project (relative path is empty).
- So if there is a pom.xml without a parent, yet in the parent `filesystem
directory` there is a pom.xml, walking up will still terminate because there is
no parent relation defined.
- This also means that in a single module project it is the same as the
`project.basedir`.
The important difference with the `multiModelDirectory` is that that one
walks up the `file system` directories until it finds a `.mvn` subdirectory (or
/). This has a real possibility of walking out of the project. So the same
project on the same machine in a directory under the same user with all
environment variables the same may still be built differently only because it
was checked out in a different subdirectory where one of the parent folders
contains a `.mvn` with some kind of config file that is picked up.
So the `topdir` definition I have in mind does not depend on the existence
of `.mvn` or `.mvnd` or anything else and as such can be used more reliably in
all projects.
> Introduce public property to point to a root directory of (multi-module)
> project
> --------------------------------------------------------------------------------
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
> Reporter: Envious Guest
> Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{<project>}}
> {{ <parent>}}
> {{ <groupId>com.acme</groupId>}}
> {{ <artifactId>corp-parent</artifactId>}}
> {{ <version>1.0.0-RELEASE</version>}}
> {{ </parent>}}
> {{ <groupId>com.acme</groupId>}}
> {{ <artifactId>multi-module</artifactId>}}
> {{ <version>0.5.2-SNAPSHOT</version>}}
> {{ <modules>}}
> {{ <module>module-a</module>}}
> {{ <module>module-b</module>}}
> {{ </modules>}}
> {{</project>}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
