OPEN QUESTION: do we deploy the newer
modelVersion POM as the
groupId:artifactId::version::pom or as
groupId:artifactId::version:build:pom? The first form ensures that the POM cannot be used as a parent by
modelVersion 4.0.0 projects as they will blow up immediately, however there has been an established practice of using
<packaging>pom</packaging> for projects that produce non-standard artifacts and want to opt-out of the standard lifecycle binding, and thus we would break consumption of those "side" artifacts by legacy clients. Perhaps the solution is to follow the second form (i.e. it gets deployed with
<classifier>build</classifier> and either put a Maven enforcer execution into the
modelVersion 4.0.0 POM or use the
<prerequisites> tag to try and at least alert that the parent is invalid.
- Herve Hervé Boutemy: Should we move away from the term Project for this document?
Issue: a "project" is either a "Top Level Project" (ex: Maven), either a "mono-module project" (ex: shared-utils), either one "module of a multi-module project" (ex: maven-artifact module of Maven core)
And even see Wikipedia "Project (disambiguation)" article: "Project, a temporary endeavor undertaken to create a unique product or service"
A build file (pom.xml when used by Maven to build an artifact) or description of attributes of an artifact is clearly not temporary
Project Dependency Trees