...
| Excerpt |
|---|
The next generation Project Object Model to be used by Maven 5.0+ |
Background
Maven uses the Project Object Model as a descriptor for the declarative build requirements of a project.
- Maven 1.x used a model which contained a
<modelVersion>3.0.0</modelVersion> element as an immediate child of the root. - Maven 2.x / 3.x has used a
<modelVersion>4.0.0</modelVersion> element.
Due to the way Maven has been implemented, the current release versions will consider any modelVersion other than the one that they target as invalid and will fail to parse the model.
For build time concerns, this is not that major a concern, and in fact may be desirable behaviour, e.g. I should not be able to build a Maven 2.x / 3.x project with Maven 1.x.
Where the modelVersion becomes a constraint, however, is when it comes to transitive dependency resolution. The Maven Central repository has grown in popularity, and now the consumers of the information in central are no longer only Apache Maven. There are other build tools that parse the POM to extract dependency information, e.g. Apache Buildr, Gradle, Apache Ivy, sbt, etc. As these build tools are not under the control of the Apache Maven project, we risk breaking their ability to parse the POM as a unit of dependency expression if we modify the pom schema or model version.
While we could change the schema if we "forked" the central repository, the experience from the previous reposotory fork (for the Maven 1.x / Model Version 3.0.0 to Maven 2.x / Model Version 4.0.0 transition) was traumatic and a repeat is generally considered to be a Bad Plan™.
The result of all this is that the Apache Maven project has been unable to evolve our POM to reflect the new needs.
The current plan for a Path Forward™ uses three legs:
- We keep deploying
modelVersion 4.0.0 poms to the repository as a best effort expression of the dependency information of artifacts such that legacy clients can continue to consume artifacts deployed with non-legacy clients. - We deploy a dependency-only model using a defined contract for forwards compatibility (to allow for future evolution) using a different file extension
- The POM then becomes a build-time only concern and does not need to be deployed to the repository - except for those cases where the pom may be used as either a parent or a mix-in
Overview
TODO write this up... I'm just dumping stuff I have done on the mail thread here to make it easier to collaborate:
...
- Content to include in the POM:
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-50 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3726 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-4506 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-4921 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-2216 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3608 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3879 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5926 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-2916 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5563 |
|---|
|
(perhaps it is a legitimate concern for plugins to require parameters that have defined values from somewhere... unclear if this affects the POM though) | Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5900 |
|---|
|
Open question do we want properties? and if we do, what interpolation rules would apply... how would parent, mix-in, platform, profiles etc take effect...| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5657 |
|---|
|
WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5659 |
|---|
|
WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness
- supports / provides type concepts:
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-177 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5652 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-1977 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-2316 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-2316 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5867 |
|---|
|
- Versioning
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-624 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-4173 |
|---|
|
(should just do this for 5.0.0. No more plugin version "magic")| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5517 |
|---|
|
WONT FIX I do not see the value in moving from the range syntax to a less mathematically complete syntax
- Lifecycle related changes
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-193 |
|---|
|
(since the symmetry will feed into the lifecycle definition syntax perhaps)| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-683 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3522 |
|---|
|
(effectively superseded as you can augment the lifecycle from within the POM and thus provide any additional phases you require in order to ensure the sequencing required)| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5384 |
|---|
|
(this one is really important as we want to be able to enable light-weight multi-module builds that just don't fail where "clean install" would succeed - solving this will mean that the reactor can proceed across all modules as required in order to deliver the requirements of the "driving" module(s))| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5665 |
|---|
|
(need to ensure that we address this need in the lifecycle declaration syntax)
- Scope related changes
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-1867 |
|---|
|
(effectively addressed above as we remove all "special" scopes replacing them with convention)| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-6107 |
|---|
|
- Better profile activation
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3326 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3826 |
|---|
|
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5650 |
|---|
|
- How to format the POM
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-3397 |
|---|
|
/ | Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5653 |
|---|
|
(effectively addressed in the current proposal)| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-6061 |
|---|
|
switching to a DSL should be considered... though I suspect a new compact XML would be less of an issue while retaining some ability to allow earlier maven versions to at least print semi-sensible errors if attempt is made to build new pom with old maven
- Mix-ins
| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5102 |
|---|
|
/ | Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5588 |
|---|
|
(should be addressed with the current proposal, but need to review what the ask in this issue was to see if any gaps exist)| Jira |
|---|
| server | ASF JIRA |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
| key | MNG-5654 |
|---|
|
(effectively addressed above)
Appendix 1 - Issues flagged for consideration post-modelVersion 4.0.0
This is not a perfect query as it includes issues that target behavioural changes outside the scope of modelVersion changes, but all the relevant issues should be a subset of this list
| Jira |
|---|
| server | ASF JIRA |
|---|
| columns | key,summary,type,description,status |
|---|
| maximumIssues | 60 |
|---|
| jqlQuery | filter=12338619 |
|---|
| serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
|---|
|
