On Nov 23, 2013, at 11:47 PM, Igor Fedorenko <[email protected]> wrote:
> > > On 11/23/2013, 23:08, Jason van Zyl wrote: >> >> On Nov 23, 2013, at 5:44 PM, Stephen Connolly >> <[email protected]> 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. > I think this sounds nice in theory but losing the information about how an artifact is produced is not a good idea. I also don't think having a bunch of different tools to read one format or another is manageable. I think that making readers that are more accepting of different versions and accommodating different elements is another approach. Keeping it all together forces you to think about the implications of a change. I think general extensibility of the format might be useful but in a general reader. Right now specific tools can work around this issue by having a plugin define specifics for a type. While not ideal it works but is more akin to a general extension mechanism that works with a single type of accommodating reader. I think splitting building vs consumption will open a huge can of worms. Now I'm all for being able to aggressively change the format, but I would rather have a single document per version of the model. Possibly think about a future proof version and publish just continue to publish a model version 4.0.0 along side it indefinitely. I'm not sure how build vs consumption actually helps us evolve the 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: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
