[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622770#comment-17622770
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288067732
> @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).
Note that with build poms, the relative path can be kept empty and it will
be inferred from the reactor. But it should be available after the first phase
of the model building IIRC.
> * 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.
It really depends on the structure of the project. Some projects may not
have their ancestor as the topmost directory. We need to cover those use cases
too. Also, it needs to work during a project-aggregation (or we need some
properties for that). I think we need to think in terms of use-cases, not
properties.
What's your first use-case for the topdir thing ?
> 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)
