[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706547#comment-17706547
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489105642
> But the parent/child relationship has to be done later in the process, so
can't be used for early interpolation.
Interpolation does not really works there anyway so no, but yes it will
require a 2 phases processing, guess it is not a big blocker as of today.
I'm not to add new properties, really just to get a single functional
rootdir one (hopefully merged with multi one but if not at least reliable on
any maven compatible projects).
My definition enables to use it for checkstyles, headers etc even without a
.mvn (whereas it works in a minority of cases - statistically - if not done
this way). It can also work when using an aggregator if the pom uses properties
to define paths exactly as .mvn case which does not solve this issue since for
a project with `root > {child1/.mvn>subchild1,child2/.mvn>subchild2}` it will
randomly take child1 or child2 as rootdir.
Side note: using .mvn also has a nasty side effect, we couldnt use it in
nested directories for module specific configuration anymore whereas it can
come later if we support lock files, dependency routing or other metadata per
module we don't want to put in the pom to keep it readable. It would be a
natural location for me.
Maybe thinking out loud but do we attack the issue by the right side, for
configuration location we want to be able to pin absolutely a file (often the
root pom), shouldn't we enable it? Main issue is that `${project.xxxx}` is
interpolated per pom so maybe we should enable a definition pinning, ie
`${project.definition.basedir}` - name is bad but sharing the idea - would stay
`/opt/foo` for `/opt/foo/pom.xml` but also its child `/opt/foo/child/pom.xml`?
This looks pretty easy to handle in interpolation and drops this `rootdir` need
in properties for user/mojo configuration. Can it be an outcome?
> 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)
