[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706527#comment-17706527
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489045762
So this PR just duplicates the properties we have without solving any new
feature but does it differently from before.
Git is different because the bubbling is cleaner whereas .mvn is an user dir
pushed to the repos (compared to git which is not) and this is what breaks
current impl as explained (agree it i as much as parent/child impl but as much
both ways).
If we can't do better than what we have today, let's keep/enhance what we
have instead of creating something very confusing for end user and not better
in terms of reliability (which prop to use being said none is really what I
want or has side effects).
> If you aggregate projects using submodules in a bigger aggregator, the
definition of the rootdir indicates it won't bubble up, and that's definitely
what we want, else the project build may fail locating files that are pointed
to.
Hmm, you can make it run in both case depending how you define it (with .mvn
in root but not children or with in children), so you still have broken cases.
If you aggregate you will get a single rootdir..so it is broken as soon as
you get 2 subprojects - actually one since parent will not have its rootdir
cleanly set.
Ideally we need a marker to set the root dir, we could use git as
inspiration and force the presence of a `.mvn/.mvn_meta` which would be handled
at "clone"/setup time somehow (do we fail if this file is missing, how do we
ensure it is not committed and experience is smooth when a project is cloned?).
The parent/child resolution + filtering to ensure the resolution does not
use .m2/remote is still way more reliable IMHO since it always works to get a
deterministic rootdir. Only case it is broken is when the child does not
reference the parent but then the intent of the user was to be able to run
either from the parent (rootdir=parent) or child only (rootdir=child) so we
always exactly match the intent whereas with .mvn we have several counter
examples since the presence is optional.
> 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)
