[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701918#comment-17701918
]
ASF GitHub Bot commented on MNG-7038:
-------------------------------------
w6et commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1474183673
> > > Do these three properties represent the same value?
> >
> >
> > I suppose you're talking about `topdir`, `project.topdir` and
`session.topdir` ? They are aliases, but I don't think the `project.topdir` is
a good idea, since it's not really a project attribute.
> > I'm still thinking about renaming the new property to `rootdir`, and
introduce a `topdir` for the execution directory in a consistent way. And
deprecate `MavenSession.getExecutionRootDirectory()`,
`MavenExecutionRequest.getBasedir()`,
`MavenExecutionRequest.getMultiModuleProjectDirectory()` accordingly. I'm open
to any naming, but things are a bit inconsistent, so I'd rather fix it.
>
> just another idea，Maybe we can define build.json(like npm's
package.json)，we can init topdir properties and other public properties in the
build.json，then generate build-lock.json\yaml, every module can use the
properties from build-lock.json, (BTW, maybe pom.xml->pom-lock.yaml，so only use
xxx-lock.yaml，so something don't need computed many times) maybe
dependencies、plugins、repositories ‘s properties can split to different
properties file，so we can import & share it for different maven project. or all
in build.json like `{ "name": "my app 001", "version": "0.0.1", "topdir":
"xxxxx", "mvn.properties": { "java.version":"17", "maven.test.skip":"true" },
"dependencies": { "compile": { "default":{ "default is required":"" },
"spring":{ "spring-amqp.version":"3.0.2" } } }, "plugins": {
>
> }, "repositories": {
>
> } } `
generated build-lock.json can contains system environment properties or
something else configuration ，so we can sure the actual
properties/configuration any which we used
> 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)
