[jira] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project

["Peter Merikan (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MNG-7038 ]


    Peter Merikan deleted comment on MNG-7038:
    ------------------------------------

was (Author: JIRAUSER287151):
I've been following this thread for a while now and I just thought I'd throw in my two cents since I'm no longer entirely sure it is what I first thought. 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). 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)
{code:java}
<configuration>
  <printFailingErrors>true</printFailingErrors>
  <failOnViolation>true</failOnViolation>
  <rulesets>
    <ruleset>${rootlocation}/etc/pmd/pmd-ruleset.xml</ruleset>
  </rulesets>
</configuration>{code}

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. 

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 is 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.

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 little more complicated. 

One solution could be to use different strategies for resolving the project root (topdir) and one strategy, and default, could be to traverse the directory tree searching for a marker (.mvn directory?). 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)