On Sunday, 24 November 2013, Jason van Zyl wrote: > > On Nov 23, 2013, at 5:44 PM, Stephen Connolly < > [email protected] <javascript:;>> 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.
I am not saying that we remove *all* other elements. I am saying that we don't really need as many of them. There are a lot of elements that have questionable utility... How often are the <developers> and <contributors> tags correct? Do we really need to know the <distributionManagement>? On the other hand there are some tags that have utility: SCM, URL, name, description, dependencies (to name a few off the top of my head) I am not saying that the above are a complete list. I am saying that this gives us an opertunity to look at this and see what we really want in the pom > > 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 > --------------------------------------------------------- > > > > > > > > -- Sent from my phone
