On Nov 24, 2013, at 3:59 AM, Stephen Connolly <[email protected]> wrote:
> 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... That may be, but they are there and you have no idea what they are being used for and again to have a new, future proof, extensible format is great. But we'll continue to publish model 4.0.0 poms. I think that's fine, I'm still not convinced making multiple documents is useful. > > How often are the <developers> and <contributors> tags correct? > We honestly have no idea. > Do we really need to know the <distributionManagement>? > For provenance possibly. > 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 > Honestly I think it would be better starting with concrete desires for additions like what Manfred described, or Tycho specific things Igor suggested and just figure out what an ideal format might look like with the two things that I think are most important: extensibility and future proofing. I don't think trying to start with the tech required for an ill defined set of actual use cases is a good idea. Most things that need to be changed can be transformed into a model 4.0.0 POM. For things that can't we can still use the technique of having a pseudo plugin that contains configuration that can change the way the core behaves. A global artifact swap for example: flip commons-logging to SLF4J. A contrived example but this can be specified in a pseudo plugin configuration. A participant can change the model before execution and it provides a way that people can try different things without changing the core directly or the pom model. I think it's a good way to try features and you just need to be using Maven 3. If we find that we like particular features the configuration in the pseudo plugin can be "graduated" to the official model and we can move code from participants into the core. Anyone can try this technique today for a feature they want in Maven. > >>> 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 Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
