Child pages
  • Build vs Consumer POM

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added a note on relation to PDT and remove import scope dependencies

...

Maven could apply same strategy: generate a consumer-only POM when publishing artifacts to a repository, with minimal information. The original POM is then called "build" POM since it contains instructions to build the artifact artifact – and the generated simplified POM is called "consumer" POM since it's intended for artifact consumers. Once this is done, we can have new build POM versions, which will require newer Maven versions to build, while consumer POM remains compatible with classical POM v4: the only requirement is to be able to generate a consumer POM (a simplified POM v4) from the original build POM used during build: flatten-maven-plugin has already proven that generating a simplified POM from the original POM and publishing it to Maven repository is feasible.

The consumer-only POM will also be easier to explain and document consumer features, without being disturbed by build content. And it's a first step towards complete separation of build and consumer features that comes with Project Dependency Trees schema proposal.

Special case: parent POMs (packaging=pom)

Parent POMs (which are POMs with "pom" packaging) don't really have any meaning as consumer POM: there is no dependency artifact to get consume from them.

They are useful only as build POMs. Moreover, they are required in Maven repositories to be used either as parent POM or as dependencyManagement import (ie imported from dependency with scope="import", evaluated only at build time).

Then non-pom-packaging POMs will be published in Maven repositories as consumer POM (v4) but pom-packaging POMs will be published in Maven repositories as build POM only (eventually using new version/format): this use case won't cause issues.

...

Consumer POM file name does not really have a meaning, but if it had, it would remain as pom.xml.

Build POM file name, while updating POM format, could be changed to something like build.xml (bad idea since it's "reserved" by Apache Ant), build.pom, or even build.json or build.yaml: not sure this would be a good idea, but at least, we can.

...

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.

hboutemy: does not explain what is useful, since flatten remove the (build) dependency (of a really different nature). Keeping parent in consumer POM will block the idea of newer POM formats for build-only that consumers ignore.

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

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

hboutemy: why?

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

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>
(plus)(warning) without system scope

system scoped dependencies removed in consumer POM (as done in flatten-maven-plugin) + import scope removed, since it's a build feature to import dependencyManagement build-only feature

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

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

...