> Date: Sat, 23 Nov 2013 23:47:55 -0500 > From: i...@ifedorenko.com > To: dev@maven.apache.org > Subject: Re: Model Version 5.0.0 > > > > 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. >
MG>good point!..which reader is default? and which version of reader to use? MG>the permutations of every reader for both format types produce daunting numbers MG>Igor ..can i assume your fallback Model would be 4.0.0? > > 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. MG>Igor..so you agree with previous paragraph? > 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. MG>How would new format be described? MG>How would new format be described in archetypes? > By separating "consumption" and "production" metadata formats, we'll be MG>How would op "migrate" from 'consumption metadata format' to 'production metadata format'? MG>Sans namespace identification (pointing to XSDs) as suggested by Paul MG>How would the plugin "know" which format to implement (consumption vs production?) > 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. MG>Tycho is latest eclipse but dont forget Europa, Ganymede, Helios, Indigo and Juno..once your are done refactoring Eclipse http://wiki.eclipse.org/Older_Versions_Of_Eclipse MG>what about MyEclipse which is based on Helios? http://www.myeclipseide.com/module-htmlpages-display-pid-342.html MG>Once Eclipse (and MyEclipse) refactorings are completed what about the thousand of users who use Idea or Netbeans? MG>Unless every IDE and every IDE variants are accomodated you could be spending 40 hours a week for months MG>at a time to refactor plugin changes to every version of every IDE...are you volunteering to be that refactoring resource? > -- > Regards, > Igor MG>Regards, Martin > > > > >> 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 >
