[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623111#comment-17623111
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
gnodet commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288878456
> The solution I've been using for the last few years is the
`build-helper-maven-plugin` and the `rootlocation` goal. I don't know how it
resolves the root location, but it has worked in all my projects without any
problems. (The only problem with this solution is that a plugin is bound to a
phase and since there is no default phase to bind to, I always have to run
validate before if I want to execute the plugin goal from the command line,
like this: `$ mvn validate spotless:check`. But that is an entirely different
issue)
Fwiw, the `build-helper-maven-plugin` uses the following heuristic: it goes
up the list of parent directories and at each step, checks if there's a
`pomx.ml`, loads it and checks if the loaded project has the current project as
a child module (so not in the sense of parent/child inheritance, but using a
`<module>` element that is used to define the reactor). The benefit is that it
works with a traditional project, even if the model's parent is not located in
the parent's directory. The particular point is that if a project is
aggregated in a bigger one, it will go up the chain, so may go out of the
project tree. And it won't stop when there's a `.mvn` project. Another
downside is that it uses maven to load the parent project so that heuristic can
not be used from early shell scripts.
> 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)
