[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706521#comment-17706521
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489020126
> I'm very confused by this PR, what I see:
>
> 1. we had 2 dir properties and they are deprecated in favor of 2 dir
properties, can't we fix the previous ones?
My option was to not break anything, it was easier to define a new set of
properties and deprecate the old ones rather than trying to find all spots
where things could be impacted.
> 2. the root dir is defined by the `.mvn` presence which is still not
mainstream so will likely always fail instead of the top dir of linked project
by the parent/child relationship defined by pom (which always works)
Well, the current definition is closer to
`maven.multiModuleProjectDirectory` which has been used for years, even if not
really public. The idea to rely on parent/child relationship just does not
work imho : first, it would have to be computed after all projects are parsed,
which conflicts with the fact that one of the use case it during project
interpolation, or even very early during the command line interpolation.
Although, there's absolutely no guarantee that it will point to the root level
of the project, as I can point to lots of projects where this would not work.
And the main use case imho it to locate files on the file system, so the
parent/child relationship is completely unrelated and would not solve the
issue. It also have to never change for any build of the project, which would
not be the case for any computation based on parent/child relationship.
> So overall think the impl should be fixed (2) and we should probably
collapse most of the properties we have, in particular for v4 where it will
just be a clean up and avoid the redefinition of new props. The big pro of root
dir is the ability to define absolutely a file config (style.xml is what i have
in mind but there are multiple cases) so should absolutely be reliable for all
projects, even without .mvn IMHO.
It is at least very precisely defined and deterministic: you start from the
`topdir` and go up until you find a `.mvn` tree. If there's none, the property
is not defined. And it is fully compatible with all existing projects, that's
the benefit of having new properties.
> 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)
