[MNG-6656] Introduce base for build/consumer process

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 4.0.0-alpha-2, 4.0.0
• Component/s: POM
• Assignee: Robert Scholte
• Reporter: Robert Scholte
• Created: 14/May/19 18:42
• Updated: 07/Nov/23 23:41
• Resolved: 22/Jun/20 19:25

Description

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

Issue Links

• causes: MNG-7923 Jenkins core does not compile with Maven 4.x
• causes: MNG-6957 Versionless reactor dependencies/parent should work even if modules are aggregated in reverse order
• fixes: MNG-6757 Cant create a proper BOM when using ${revision}
• fixes: MNG-624 automatic parent versioning
• incorporates: MNG-4463 Dependency management import should support version ranges
• incorporates: MNG-7136 Update Maven modules structure schema to add new components
• is a parent of: MNG-7182 Use a pull parser during the build/consumer transformation
• is blocked by: MNG-5669 same pom.xml is read multiple times
• is related to: MNG-6846 conditional overwrite
• relates to: MNG-7044 Allow use of attributes in Maven pom.xml
• relates to: MNG-6753 MavenMetadataSource should not use ProjectBuilder
• requires: MNG-6399 Lift JDK minimum to JDK 8
• supercedes: MNG-6608 Why can't project.version in pom.xml be set as a variable?
• links to: GitHub Pull Request #66
• links to: GitHub Pull Request #286
• links to: GitHub Pull Request #510
• mentioned in: Page Loading...