[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6656:
--------------------------------
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|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}}
was:
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 poms and to make it possible to work
on model 5.0.0.
During install/deploy the pom.xml will be adjusted. At first this means
removing the modules and adjusting the relativePath elements.
This is done for the following reasons:
- these elements refer to relative paths on a local system. Once published
these elements don't have any value anymore.
- It will give us experience with manipuating files 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
> Introduce base for build/consumer pom
> -------------------------------------
>
> 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-candidate
>
>
> 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.2#803003)
