...
field | status for consumer | comment |
---|---|---|
<modelVersion/> | not absolutely required, but kept as usual convention | |
<parent> | content inlined in consumer POM, because we can and it will simplify consumers code rfscholte: should stay ensure the calculation of distances of dependencies. Only the relativePath can be removed, since it point to a File on the local system. | |
<groupId/> | ||
<packaging/> | not absolutely required, since packaging is more a build configuration than something consumers may use | |
<name/> | necessary because of minimal requirements for central | |
<description/> | necessary because of minimal requirements for central | |
<url/> | necessary because of minimal requirements for central | |
<inceptionYear/> | ||
<organization> | ||
<licenses> | necessary because of minimal requirements for central | |
<developers> | necessary because of minimal requirements for central | |
<contributors> | rfscholte: should stay. If people want to remove it, they should use flatten-maven-plugin | |
<mailingLists> | ||
<prerequisites> | used for plugins, to define runtime Maven version prerequisite | |
<modules/> | rtfscholte: not an issue, only allowed for packaging pomrfscholte: points to a File on the local system, hence can always be removed. | |
<scm> | necessary because of minimal requirements for central | |
<issueManagement> | ||
<ciManagement> | ||
<distributionManagement> | keep downloadUrl field only rfscholte: not up to us. Is people want to remove it, they should use flatten-maven-plugin | |
<properties> | values inlined in consumer POM rfscholte: all dependency-related segments should stay, which means properties too because they can be used as part of the dependency | |
<dependencyManagement> | rfscholte: all dependency-related segments should stay | |
<dependencies> | system scoped dependencies removed in consumer POM rfscholte: all dependency-related segments should stay, if we allow system-scope at build-time, it must also be consumable. | |
<repositories> | need to check if repositories configured in dependencies are used during resolution rfscholte: all dependency-related segments should stay | |
<pluginRepositories> | ||
<build> | ||
<reports/> | let's remove this old Maven 1 compatibility field... | |
<reporting> | ||
<profiles> | ||
<id/> | ||
<activation> | keep JDK and OS activation only? removing other activations, which are build time. Same as flatten-maven-plugin feature | |
<dependencies> | ||
<build> | since removed from base model all dependency-related segments should stay |
...