For that to work you'd basically need to be able to round-trip between the yaml format and the xml format...
otherwise the tooling in IDEs and in plugins like versions-maven-plugin, maven-release-plugin, etc will make changes and very soon the yaml file is just the seed file and bares no resemblance to the current canonical form. >From trying to rewrite XML without changing the formatting... all I can say to you is good look getting a yaml -> xml -> yaml round trip without screwing up the formatting and comments that fools have put in. Another issue I see is, how to handle the configuration section... e.g. maven-antrun-plugin What about if we add support for XML PI's in versions-maven-plugin (I'm thinking of using them as processing instructions for versions-maven-plugin to allow it to know what to do with dependencies) There's a lot of stuff that XML can support and I think you're just thinking about the simple XML used for 99% of pom.xml files.... 2009/9/8 Christian Edward Gruber <[email protected]> > So - 2 points. > > 1. Who's saying you have to actually have YAML poms IN the maven project - > as long as I can find a way to (through autodiscovery of some mechanism) not > have to do crazy wrappers. You said these extension points would be there, > so I'm happy. (do note the smiley) > > 2. Who's saying you ahve to change the internals of the maven pom in a way > that would screw with integrations like m2eclipse, etc. Not I. Note, I > said canonical format, and someone else (can't remember who) pointed out > that the object model is the truly canonical metadata model. That's fine > with me. I'm talking about pre-generating in a way that's transparent from > the CLI. If that's by extensions, fine. I just would rather not have mvn > wrapper scripts to do it. > > Christian. > > > > On Sep 8, 2009, at 3:35 AM, Jason van Zyl wrote: > > >> On 2009-09-08, at 4:12 AM, Christian Edward Gruber wrote: >> >> On Sep 7, 2009, at 9:52 PM, Ralph Goers wrote: >>> >>> At one point the pom was going to be "redone" so that it wasn't going to >>>> be completely compatible. Later, I think the decision was made to keep it >>>> compatible. At one point there was support for having different pom formats >>>> but I'm not really sure what the state of that is. >>>> >>> >>> I asked if we could have yaml poms, and some of the committers said "no." >>> ;-) >>> >>> >> The flexibility will be in the Maven framework, not what we expose in the >> Maven CLI. The difference being the onus of support is not the burden of >> this project but whomever decides to make their variant of the POM. This is >> not a small change in behaviour or interoperability. >> >> Not exactly that simple, but the usual arguments about standardization >>> vs. flexibility in the tool were levied. >>> >>> On that point, perhaps one way to handle this is to do something like >>> this: >>> 1. Require all maven poms released in an organization inherit the global >>> metadata. >>> 2. Any pom (of any type) would load this metadata >>> 3. Run would fail because of a restriction in the parent pom on available >>> formats (for organizational standardization). >>> >>> The argument about maven-wide standardization is, I believe, the >>> developers imposing a style based on a preference. If my whole organization >>> wants to roll yaml poms, I can't see why we shouldn't. >>> >> >> There would be nothing stopping you at all from doing this. The onus of >> support is on you. This is one of the primary goals of the changes in Maven >> 3.x is to easily allow extensions. For integrators to provide extensions and >> to support them, not for us at the project to support. >> >> >>> Having to do a second translation layer outside of maven means that for >>> us to standardize on something that makes us more productive and less prone >>> to error, we have to use a more brittle approach because of an unnecessary >>> design decision of the tool. Pick a canonical format, sure, but for >>> source... Heck, Maven builds that concept into its java lifecycle, with >>> generated code. Imagine if the build tool determined that I could only use >>> JACC, and that ANTLR wasn't part of the "maven" set. >>> >>> >> This may very well happen in the future. But there are far more important >> concerns and mixing in trying to support variants of the POM in the first >> release cycle of 3.0 would be a complete and total disaster. We would have >> 198 variations because people think they have something better. Each one of >> them with a valid arguments as to why they are better. So instead of >> debating the merits of format we will give you the ability to support your >> format. It's outside the scope of Maven proper. >> >> I would like people to actually try this as then we'll see what the >> outcome is without there being serious damage on the Maven side. The fact is >> we don't actually know what would happen and it's not going to be an >> experiment in Maven. I don't think people understand the real impact of >> changing so fundamental as the POM format: >> >> - All examples in books and existing documentation become invalid >> - Maven tooling like M2Eclipse, Netbeans and IDEA become immediately >> useless until the tooling catches up >> - Interoperability becomes impossible in the short term >> >> These are not insignificant issues and are _extremely_ costly to support. >> There is the problem here in the Maven project itself, but allowing >> arbitrary POM formats then imposes huge support costs on people who have >> invested in Maven tooling. >> >> For all of these reasons it's not going to happen quickly in Maven itself >> that we change the format. The extension points will be there and folks can >> do as they like but it's just not something I think we can feasibly support >> in Maven. >> >> Go for standardization, pick sane, well documented defaults, but don't >>> bake in design decisions that don't conflict with those principles (if >>> possible). >>> >>> Anyway - that's just a recap of my position. Focus on standardization >>> and not breaking existing anything came up (though I think spuriously, since >>> a canonical format would take care of that). Heck, we allow >>> maven-antrun-plugin executions for arbitrary crap, so at least if we're >>> going to script, we do it consistently in the lifecycle. Just make this a >>> pre-processing step. >>> >>> cheers, >>> Christian. >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> http://twitter.com/SonatypeNexus >> http://twitter.com/SonatypeM2E >> ---------------------------------------------------------- >> >> >> --------------------------------------------------------------------- >> 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] > >
