Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

fieldstatus for consumercomment
<modelVersion/>
(thumbs up)not absolutely required, but kept as usual convention
<parent>
(minus)

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/>
<artifactId/>
<version/>
(plus) 
<packaging/>
(thumbs up)not absolutely required, since packaging is more a build configuration than something consumers may use
<name/>
(plus)necessary because of minimal requirements for central
<description/>
(plus)necessary because of minimal requirements for central
<url/>
(plus)necessary because of minimal requirements for central
<inceptionYear/>
(thumbs up) 
<organization>
(thumbs up) 
<licenses>
(plus)necessary because of minimal requirements for central
<developers>
(plus)necessary because of minimal requirements for central
<contributors>
(question)rfscholte: should stay. If people want to remove it, they should use flatten-maven-plugin
<mailingLists>
(thumbs up) 
<prerequisites>
(plus)used for plugins, to define runtime Maven version prerequisite
<modules/>
(minus)rtfscholte: not an issue, only allowed for packaging pomrfscholte: points to a File on the local system, hence can always be removed.
<scm>
(plus)necessary because of minimal requirements for central
<issueManagement>
(thumbs up) 
<ciManagement>
(thumbs up) 
<distributionManagement>
(warning)
keep downloadUrl field only

rfscholte: not up to us. Is people want to remove it, they should use flatten-maven-plugin

<properties>
(minus)

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>
(minus)rfscholte: all dependency-related segments should stay
<dependencies>
(plus)(warning) without system scope

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>
(question)

need to check if repositories configured in dependencies are used during resolution

rfscholte: all dependency-related segments should stay

<pluginRepositories>
(minus) 
<build>
(minus)(thumbs up) this is where the addition of new configuration to enhance Maven build features will be the most useful
<reports/>
(minus)let's remove this old Maven 1 compatibility field...
<reporting>
(minus) 
<profiles>
(plus) 
    <id/>
(plus) 
    <activation>
(question)(warning)keep JDK and OS activation only? removing other activations, which are build time. Same as flatten-maven-plugin feature
    <dependencies>
(plus) 
    <build>
    <modules/>
    <distributionManagement>
    <properties>
    <dependencyManagement>
    <repositories>
    <pluginRepositories>
    <reports/>
    <reporting>
(minus)

since removed from base model

all dependency-related segments should stay

...