Page History

<modelVersion/>

<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.

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.

hboutemy: does not explain what is useful, since flatten remove the (build) dependency (of a really different nature)

<groupId/>
<artifactId/>
<version/>

<packaging/>

<name/>

<description/>

<url/>

<inceptionYear/>

<organization>

<licenses>

<developers>

<contributors>

<mailingLists>

<prerequisites>

<modules/>

<scm>

<issueManagement>

<ciManagement>

<distributionManagement>

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.

hboutemy: original location is a build feature, nobody at SBT or other build tool generate a pom.xml with this field because they use their build tool to push

<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

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.

hboutemy: why?

<dependencyManagement>

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.

hboutemy: in theory, yes. In practice, people write super poms for that. And that's yes a little new constraint to add: you must create a bom when you want a bom. Removing this from normal poms will just make clear that it's not used in normal dependencies, which are 99% of the time

<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.

hboutemy: ok, why not, I won't fight on this one (not a good practice, but that's life)

<repositories>

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.

hboutemy: the question is: is it really used currently? (to avoid the dependencyManagement effect: people think it is used in dependencies, but it is not...)

<pluginRepositories>

<build>

<reports/>

<reporting>

<profiles>

    <id/>

    <activation>

    <dependencies>

    <build>
    <modules/>
    <distributionManagement>
    <properties>
    <dependencyManagement>
    <repositories>
    <pluginRepositories>
    <reports/>
    <reporting>

since removed from base model

all dependency-related segments should stay