[ 
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701916#comment-17701916
 ] 

ASF GitHub Bot commented on MNG-7038:
-------------------------------------

w6et commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1474173520

   > > 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": {
   
     }
   }
   `
   




> 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)

Reply via email to