Child pages
  • Build vs Consumer POM

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.

hboutemy: I don't see how parent has anything to do with distance of dependencies

rfscholte: parent is a special kind of dependency, all dependency related-segments should stay.

<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>
(thumbs up)If people want to remove content, the generation should be parametrized
<mailingLists>
(thumbs up) 
<prerequisites>
(plus)used for plugins, to define runtime Maven version prerequisite
<modules/>
(minus)rfscholte: 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

hboutemy: how is this information useful for consumers?

rfscholte: it is not build-related, which is enough reason for me to keep it, it is about the distribution. It shows the original location from which it was spread into the world.

<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

hboutemy: isn't what flatten-maven-plugin does?

rfscholte: this consumer-pom is not the same as flatten-maven-plugin. The flatten-maven-plugin is a decision by the developers to resolve all properties. We should not do that by default.

<dependencyManagement>
(minus)

rfscholte: all dependency-related segments should stay

hboutemy: how is it useful for consumers?

rfscholte: it is not build-related. e.g. even the pom of a jar can be used as bom. Maven allows it, so we should not try to simply remove it.

<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

hboutemy: how is it useful for consumers?

rfscholte: required if dependencies needs to be downloaded from a different repository.

<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

...