Yes, the XML is verbose, and tooling helps but I think most people write it by hand. The only evolutionary change I support is the ability to specify simple nested elements as attributes.
Paul On Fri, Sep 4, 2009 at 4:40 PM, Jason Chaffee <jason.chaf...@zilliontv.tv>wrote: > For what it is worth, I have heard many complaints either about using XML > and/or about the current structure of the XML as well. I have heard this > from developers I have worked with and I have read some blogs about this > too. I can't tell you where those blogs are now because I pretty much > dismissed them as I like using XML myself. > > Jason > ________________________________________ > From: Christian Edward Gruber [christianedwardgru...@gmail.com] > Sent: Friday, September 04, 2009 2:29 PM > To: Maven Developers List > Subject: Re: Re : non-xml poms in 3.x > > Who said anything about a reasonable person? :) I don't have such a > hatred - I'm quite used to it, but it has come up in nearly every > client in the last 3 years - not as a final or deal-breaking barrier > to adoption, but a barrier nonetheless. > > I'm happy to support it - I just need a seam or hook where I can > provide something that pre-processes before the maven run to generate > the pom.xml. Maven itself doesn't need to support the alternate > format at all. If it could be something that was auto-detected as > well (or at worst, put into a settings.xml) then that'd be great. > Essentially I'm doing that now with the maven-yamlpom-plugin... it's > just that I have to do a separate run because it modifies the pom.xml, > and so maven fails on the first sync because the pom was modified. > > In a pinch, this can all be handled with shell scripts wrapping maven, > but I'd prefer to have a cleaner place to integrate. > > Christian. > > On Sep 4, 2009, at 5:12 PM, Jason van Zyl wrote: > > > > > On 2009-09-04, at 10:59 PM, Christian Edward Gruber wrote: > > > >> So I agree that it is a valid concern, and there needs to be a > >> canonical format (which will probably be XML) which all artifacts > >> are saved as - but in my source tree, it should be entirely > >> possible to have an alternate way to specify, since often I've > >> found that XML-hatred is a barrier to Maven adoption in some firms. > >> > > > > I have not found this to be a concern. There's lots of other things > > that are barrier but the XML has honestly never come up in any > > conversations I've had. > > > >> You should always be able to get the pom.xml... help:canonical-pom > >> would be a decent way to quickly do it, and artifacts should be > >> published that way - but a Project is an object, and alternate > >> serializations shouldn't be a problem. > > > > Therein lies the problem, the only real canonical form is the object > > model. With 3 XML formats which one is the canonical format? The > > first one? > > > >> > >> I would, also as an evangelist and implementor of build systems in > >> companies, encourage that a company standardize on a format, but if > >> that company wants to use YAML, or some other terser, more human > >> readable format for the pom, then I'm good with that. > > > > I'm not. Again this falls into my category of "if you want it that > > way, you support it." A company can standardize on whatever it > > wants, but I'm not going to hide the real cost of that. We may > > ultimately decide it's not worth it having another XML format. There > > are a lot more things in 3.0 that interest me then another XML format. > > > >> > >> I used to feel more like you, Brian, but for the sheer intensity of > >> hatred of XML out there (as a format for human-maintained source). > >> > > > > Again, I've not witnessed any XML hatred or that being a > > justification by a reasonable person not to use Maven. > > > >> The problem you're describing about one project using one and > >> another using a different one - that's no different than one > >> project deciding to use a different set of integration test plugins > >> (invoker vs. shitty) and confusing the noobs. The bottom line is > >> that you're not going to be able to constraint people from going > >> for the "new thing" and messing up the inexperienced, so providing > >> sane defaults with lots of room to customize is the best option, in > >> my view. > >> > >> Christian. > >> > >> > >> On Sep 4, 2009, at 4:25 PM, Brian Fox wrote: > >> > >>>> Just my 2 cents as a Maven evangelist in a big private company. > >>>> Even if > >>>> Maven is around for years now, basic endusers just start to get > >>>> accustomed to pom.xml and Maven philosophy (really! people are > >>>> far slowest to change than in OpenSource project team). > >>>> > >>>> Please, please don't mess everything. Small additions are fine, > >>>> but I think a new format is a bad idea even if it is optional. > >>>> One of advantage of Maven is standardization across all our > >>>> projects. If there are several format allowed, some projects will > >>>> start using new one when others are still using the former and it > >>>> will lead to a total mess. > >>>> > >>> That's my main concern as well to be honest. > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > http://twitter.com/SonatypeNexus > > http://twitter.com/SonatypeM2E > > ---------------------------------------------------------- > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
