[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623099#comment-17623099
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
merikan commented on PR #840:
URL: https://github.com/apache/maven/pull/840#issuecomment-1288845375
I've been following this thread and I just thought I'd throw in my two
cents. This is what my use case looks like:
Over the years I have built a number of multi-modular projects that have
spring-boot as a parent. I have a number of artefacts in the root (folder) that
I want to access from my sub-modules (pmd, spotbug, spotless, dependency-check,
etc).
```
root
├── etc
├── module1
├── module2
├── module3
└── pom.xml
```
Initially I was using a build-module but since it was used as a dependency
and was not always available I gave up using that approach.
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)
```
<configuration>
<printFailingErrors>true</printFailingErrors>
<failOnViolation>true</failOnViolation>
<rulesets>
<ruleset>${rootlocation}/etc/pmd/pmd-ruleset.xml</ruleset>
</rulesets>
</configuration>
```
I guess most Maven projects probably use, for the sake of simplicity and
probably the most intuitive, a direct hierarchical structure which is also
reflected on the file system. So do I, with a few exceptions where I used a
parent module that was next to the child modules. When using the
`relativePath` element, we can have all sorts of parent-child relationships
where submodules might have different parents and it can get very complicated.
Most people probably like to think of a common ancestor in a project but it is
not, as I understand it, something that maven imposes.
I understand that people can have quite complex project structures and maybe
also in a mono-repo and that Maven should be able to support it. To me it
sounds reasonable to assume a `.mvn` directory as the root when using a
subfolder structured project but there may be use cases where that is not
correct either.
For me, regardless of which submodule I'm building from, I want to be able
to find my shared artefacts up in the hierarchy (file structure). This is what
many tools does and most people are used to it and it is quite accepted. I do
think that mixing it with pom parent relation makes it a lot more complicated.
One solution could be to use different strategies for resolving the project
root (topdir) and one strategy, the default one, could be to traverse the
directory tree searching for a marker, e.g. `.mvn` directory. To make it more
flexible when traversing the tree, then maybe it should be possibility for the
user to override the marker, for what is considered a project root, with
another directory or filename.
> 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)
