On 11/23/2013, 23:08, Jason van Zyl wrote:
On Nov 23, 2013, at 5:44 PM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
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.
Can you explain why you think this is useful? To me all the
information that is carried with the POM after deployment is
primarily for the consumption of tools, and there are a lot of tools
that expect more than the dependency information. Removing all other
elements in the POM is equivalent to being massively backward
incompatible for an API. And if the subsequent consumption after
deployment is primarily by programs, then why does it matter what
gets deployed. I don't really see much benefit, but will create all
sorts of technical problems where we need multiple readers and all
that entails and the massive number of problems this will cause
people who have created tooling, especially IDE integration. >
The way I see it, what is deployed describes how the artifact needs to
be consumed. This is artifact's "public API", if you will, it will be
consumed by wide range of tools that resolve dependencies from Maven
repositories and descriptor format should be very stable. Mostly likely
we have no choice but use (a subset of) the current 4.0.0 model version.
How the artifact is produced, on the other hand, is artifact's
implementation detail. It is perfectly reasonable for a project to
require minimal version of Maven, for example. Or use completely
different format, not related to pom at all.
By separating "consumption" and "production" metadata formats, we'll be
able to evolve production format more aggressively. For example, it
would be nice to have Tycho-specific configuration markup inside <build>
section. This is not currently possible because all poms must be
compatible with the same model.
--
Regards,
Igor
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.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
