Before I forget, here are some of my thoughts on moving towards Model
Version 5.0.0
The pom that we build with need not be the pom that gets deployed...
thus the pom that is built with need not be the same format as the pom
that gets deployed.
Only with <packaging>pom</packaging> do we actually need things like the
<plugins> section in the deployed pom, because it is a reality that for
noo-pom packaging we just want the transitive dependencies.
Now there is the <extensions> issue where you might be registering a
different file type that has different rules with respect to the
classpath... but I am unsure if we actually consider those when evaluating
the dependency tree... and in any case, once we accept that the deployed
pom is not the same as the pom used to build (for non-pom packaging at
least) we can transform that dependency tree using the exact rules that
have to be known at build time thus closing the extensions issue.
For projects with <packaging>pom</packaging> in fact we are only deploying
smal files so perhaps we can deploy two pom files... the one that exposes
the standard dependency stuff and then a second one that is used for build
inheritance.
My vision is thus that we deploy between 2 and three pom files for every
project.
For jar/war/ear/... we deploy:
* a modelVersion 4.0.0 pom as .pom (only lists dependencies)
* a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
for new scopes)
For pom we deploy
* a modelVersion 4.0.0 pom as .pom (only lists dependencies)
* a modelVersion 5.0.0 pom as -v5.pom (only lists dependencies but allows
for new scopes)
* the pom itself
When building a pom, your parent pom must be of a modelVersion <= your
modelVersion.
