[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706535#comment-17706535
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489078230
> 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.
But the parent/child relationship has to be done later in the process, so
can't be used for early interpolation. If you can come up with a nice
definition, we can define additional properties. Although, those are already
available from various plugins, so not sure we do actually need them, unless
there is pressing needs, but I still don't grab the use case for those. For
example, they could not be used to locate checkstyle rules, headers files and
such, as those have to be local to the project when aggregated in a bigger
reactor. For those, the `.mvn` does work reliably. So what's your use case ?
> 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)
