On Nov 24, 2013, at 10:28 AM, Benson Margulies <[email protected]> wrote:
> It seems to me that this thread is mixing two topics. > > Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy > XML-parsing POM consumers? > > Topic #2: To what extent does the pom mix a 'description of contract' > (dependencies, etc) with a 'specification of build'? > > On the first topic, there was a wiki page months ago that explored a > scheme for writing both a v4 pom and a v5 pom when deploying from a v5 > project, so that old tools could see and consume what they understand. > To the extent that this scheme made sense, it can be adopted without > (necessarily) touching the second. > If you are referring to this: https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model Then I think what this document lacks are the use cases that drive anything. Without actually having some target features you cannot understand what you require technically. I think from the discussion thus far we have the following features: - API provides (from Stephen) - Runtime requirements (from Manfred) - Global excludes (much asked for feature) - Global swaps (much asked for feature) Additionally by requirements: - Are we going to allow for extensibility? - Are we going to be future proof? - Are we going to provide backward compatibility? I believe this is where we start. Many of the answers about how the implementation will look will be driven by specific features and answers to requirements questions. > On the second topic, I'm in agreement that there should be a clear > separation between describing a contract and other things. For > example, why is it a good idea for deployed poms to reference parents, > rather than being self-contained? Why is it a good idea for deployed > poms to include profiles? Why is it a good thing for deployed poms to > include parameter references, thereby in some cases accidently > changing their semantics due to collisions with the consuming > application's pom? The full 'here's how to build' pom, in my view, is > part of the source, and should be deployed with the source, and any > tool that can usefully analyze the details (plugins, pluginManagement, > etc) is welcome to do so. Having written this, it also seems to me > that one compromise could be that v5 deployed poms could be > self-contained, complete, but organized so as be clear as to the two > categories of contents. > > > > On Sun, Nov 24, 2013 at 9:29 AM, Igor Fedorenko <[email protected]> wrote: >> I think we are saying the same thing -- we evolve project model used >> during the build but deploy both the new and backwards compatible models. >> >> One quick note on representing dependencies as provided/required >> capabilities. Although I like this idea in general, I believe it will >> require completely new repository layout to be able to efficiently >> find capability providers. Single repository-wide metadata index file, >> the approach implemented in P2 for example, won't scale for repositories >> of the size of Central, so most likely the new repository layout will >> require active server-side component to assist dependency resolution. >> >> -- >> Regards, >> Igor >> >> >> On 11/24/2013, 4:25, Stephen Connolly wrote: >>> >>> 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 >>>>> <[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. >>> >>> >>> >>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > 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 ---------------------------------------------------------
