On Sunday, 24 November 2013, Igor Fedorenko wrote: > > > 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.
I would be very sad if we are limited to a subset. There are some critical concepts that in my view are missing from pom files. Number one on my hit list is a <provides> concept. Where you declare that an artifact *provides* the same api as another GAV. Technically you'd need to be able to specify this both at the root of a pom and also flag specific dependencies (because the api they provide was not specified when that pom was deployed) Thus the Geronimo specs poms could all <provides> the corresponding JavaEE specs and excludes issues or other hacks would no longer be required. Look at the issues you will have if you use the excludes wildcards in your pom... Namely *anyone* who uses your artifact as a dependency will need to be using Maven 3 or newer... does ivy read those wildcards correctly? Does sbt? Does Buildr? They are a tempting siren... And from another PoV they will force others to follow... *but* if we are forcing them to follow should we not pick a nicer format to follow... Not one consisting of many layers of hacks? The modelVersion 4.0.0 pom is deployed to the repo (in my scheme) so that legacy clients can still make some sense... If a modelVersion 5.0.0 feature cannot be mapped down to 4.0.0... Well we try our best and that's what you get... We should make it sure that people stuck with older clients can read something semi-sensible and then layer their hacks as normal to get the behaviour they need. Thus <provides> (which is not a scope but a GAV) can be modelled by having the modelVersion 4.0.0 pom list the collapsed dependencies with the appropriate <excludes> added (without wildcards) Other concepts cannot be mapped, so they get dropped. > 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. Exactly... The pom used to build can be written in JSON or whatever domain specific DSL you want... We deploy a modelVersion 5.0.0 pom as XML because it will be read my machines. Now for the reason I think deploying a pom as xml may be a good thing... XSLT Suppose we specify a XSLT GAV that will down-map the pom to a modelVersion 5.0.0 pom... Now we can actually deploy a modelVersion 7.3.5 pom to the one GAVCT and a modelVersion 5.0.0 client reads is, sees it is a modelVersion that is not understood, sees the GAV of the XSLT, pulls it down and transforms the model into the version it can parse Will it be able to parse all the info in the original pom? Nope... It's an older client... Older clients should not expect to grok all the subtleties of newer poms... But it should get the general shape In all of the above, <packaging>pom</packaging> is special... We just deploy that as is in whatever format (JSON/DSL/XML/groovy/etc) as the -build.pom So 4.0.0 => .pom 5.0.0 onward (XSLT down versioning) => -dep.pom And as a parent =< -build.pom Modern clients can ask for the -dep.pom first... And fall back to the .pom It's not perfect, but it should not be the hell of 3.0.0->4.0.0 the fear of which has prevented forward progress since > 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 > > -- Sent from my phone
