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

Hudson commented on MNG-6656:
-----------------------------

Build unstable in Jenkins: Maven TLP » maven » MODELTESTS_IMPROVEMENT #26

See 
https://builds.apache.org/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/26/

> Introduce base for build/consumer process
> -----------------------------------------
>
>                 Key: MNG-6656
>                 URL: https://issues.apache.org/jira/browse/MNG-6656
>             Project: Maven
>          Issue Type: New Feature
>          Components: POM
>            Reporter: Robert Scholte
>            Assignee: Robert Scholte
>            Priority: Major
>             Fix For: 3.7.0
>
>         Attachments: MNG-6656.zip
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do 
> improvements as long as the local pom (as part of the sources) is exactly the 
> same as the file being published.
> For the Maven eco system it is important that the published file will still 
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The 
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly 
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will 
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter 
> will get the version based on the relativePath. If the groupId and artifactId 
> don't match, the version can't be solved and Maven will fail with a missing 
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor 
> dependencies, the filter will look up the matching version. If there's no 
> version for the groupId+artifactId, the version can't be solved and Maven 
> will fail with a missing version for the dependency. 
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and 
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not 
> useful after building
> - Remove the relativePath-element, since this is local path information and 
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during 
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with 
> the System property {{maven.experimental.buildconsumer=true}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to