[jira] [Commented] (MNG-8072) Add a consumerPomFile to the MavenProject

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

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

laeubi opened a new pull request, #1437:
URL: https://github.com/apache/maven/pull/1437

   Currently there is some vague definition of a "build pom" versus a "consumer pom":
   
   - https://maven.apache.org/studies/consumer-pom/
   - https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
   
   there are also some plugins around to work with this e.g.
   
   - 
   - https://tycho.eclipseprojects.io/doc/latest/tycho-packaging-plugin/update-consumer-pom-mojo.html
   - https://www.mojohaus.org/flatten-maven-plugin/plugin-info.html
   
   but there are some issues:
   
   1. Maven makes some assumptions about its "file", e.g setting the file
   2. changes the basedir
   3. Even though there is a setPomFile method that do not change the
   4. basedir e.g. a parent ref by default would be broken
   5. once we change the file, there is a mismatch between the pom on disk
   6. and the model
   7. it is not possible for a plugin to know the original file and the
   8. consumer file, e.g. if I want to deploy the original file e.g. with classifier "pom-build"
   9. because of this usually "consumer pom plugins" generate the the new
   10. pom to a new file in the project root, where it actually not belongs to and leaves the file even after mvn clean if no special actions are taken.
   
   This enhance the MavenProject with one more method set/getConsumerPom that fills this gap, then plugins working on the consumer pom can set the file there and where it then is used by other plugins.
   
   Following this checklist to help us incorporate your
   contribution quickly and easily:
   
    - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG-8072) filed
          for the change (usually before you start working on it).  Trivial changes like typos do not
          require a JIRA issue. Your pull request should address just this issue, without
          pulling in other changes.
    - [x] Each commit in the pull request should have a meaningful subject line and body.
    - [x] Format the pull request title like `[MNG-XXX] SUMMARY`,
          where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue.
    - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`.
          Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
    - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
    - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will
          be performed on your pull request automatically.
    - [ ] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under
   the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
    - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
    - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   




> Add a consumerPomFile to the MavenProject
> -----------------------------------------
>
>                 Key: MNG-8072
>                 URL: https://issues.apache.org/jira/browse/MNG-8072
>             Project: Maven
>          Issue Type: Improvement
>            Reporter: Christoph Läubrich
>            Priority: Major
>
> Currently there is some vague definition of a "build pom" versus a "consumer pom":
> * https://maven.apache.org/studies/consumer-pom/
> * https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> there are also some plugins around to work with this e.g.
> * https://tycho.eclipseprojects.io/doc/latest/tycho-packaging-plugin/update-consumer-pom-mojo.html
> * https://www.mojohaus.org/flatten-maven-plugin/plugin-info.html
> but there are some issues:
> # Maven makes some assumptions about its "file", e.g setting the file changes the basedir
> # Even though there is a setPomFile method that do not change the basedir e.g. a parent ref by default would be broken
> # once we change the file, there is a mismatch between the pom on disk and the model
> # it is not possible for a plugin to know the original file and the consumer file, e.g. if I want to deploy the original file e.g. with classifier "pom-build"
> # because of this usually "consumer pom plugins" generate the the new pom to a new file in the project root, where it actually not belongs to and leaves the file even after mvn clean if no special actions are taken.
> I therefore like to suggest to enhance the MavenProject with one more method set/getConsumerPom that fills this gap, then plugins working on the consumer pom can set the file there and e.g. https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html can look there first, or even have an option to deploy both poms automatically if they differ.
> Of course this will be nothing happen right now but looks like something that can become useful over time and maybe fully adapted in Maven4.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)