Cool. Good to hear.
On Sep 5, 2009, at 1:42 PM, Jason van Zyl wrote: > > On 2009-09-05, at 10:23 PM, Jason Chaffee wrote: > >> I agree with you and Jason van Zyl about Maven probably doesn't need >> to support another option. However, it would be nice if the >> architecture supported it more easily. >> > > It does and I used it in a prototype Groovy and JRuby sort of version > of Maven > >> This would mean everything is accessed through a clean API and that >> we could easily inject our own POM parser. If someone wrote a >> plugin that didn't use the API's correct and bound to the XML, then >> the person that injected his own POM parser and POM format would be >> left to deal with that too. He/She would have to decide if it is >> worth it for them. I imagine some people would still do it and >> either sacrifice the use of those plugins or they help to contribute >> to fix them to work the API more appropriately, thus giving back to >> the community in a constructive manner. >> >> The current problem is that some of the maven code is very nasty and >> some it isn't always easy to inject your own implementations into it. >> >> The way I see it, it is more about building a nice injectable >> architecture with really good clean API's, then power users can >> basically do whatever they want easily. Therefore, you wouldn't be >> directly supporting this feature...but by creating a clean >> injectable architecture you would support without that intent anyway. >> >> This way, the maven team isn't supporting it per se, but rather the >> architecture supports the ability for someone to do it at their own >> risk. >> >> >> kind regards, >> >> Jason >> >> >> ________________________________________ >> From: Stephen Connolly [[email protected]] >> Sent: Saturday, September 05, 2009 5:45 AM >> To: Maven Developers List >> Cc: Maven Developers List >> Subject: Re: Re : Re : non-xml poms in 3.x >> >> personally, given the fun with rewriting XML at the moment, (see >> versions maven plugin) I would prefer to just have the current XML >> format. adding more formats makes some of the things that the >> versions >> maven current does a little harder to support. >> >> Sent from my [rhymes with myPod] ;-) >> >> On 5 Sep 2009, at 12:00, Julien HENRY <[email protected]> wrote: >> >>> In the very specific case of groupId/artifactId/version pattern >>> which is currently very verbose I would tend to agree to allow >>> shorter syntax using attributes instead of elements. >>> >>> <dependency groupId="" artifactId="" version="" classifier="" >>> scope=""/> >>> >>> <plugin groupId="" artifactId="" version=""> >>> <configuration> >>> ... >>> </configuration> >>> </plugin> >>> >>> This is not what I consider a "big" change for endusers. >>> >>> Still my 2 cents. >>> >>> Regards, >>> >>> Julien >>> >>> >>> >>> ----- Message d'origine ---- >>>> De : Jason Chaffee <[email protected]> >>>> À : Maven Developers List <[email protected]> >>>> Envoyé le : Samedi, 5 Septembre 2009, 1h00mn 02s >>>> Objet : RE: Re : non-xml poms in 3.x >>>> >>>> FYI, I know that in the past Resin supported both Elements and >>>> attributes in >>>> it's config XML. It was really neat. If you preferred one over >>>> the other, you >>>> could use it. Don't know if it is still that way though. >>>> >>>> Jason >>>> ________________________________________ >>>> From: Jason Chaffee [[email protected]] >>>> Sent: Friday, September 04, 2009 3:27 PM >>>> To: Maven Developers List >>>> Subject: RE: Re : non-xml poms in 3.x >>>> >>>> I like the idea of having some things as attributes. >>>> >>>> See the following links on information on when to use attributes >>>> and when to use >>>> elements. >>>> >>>> http://www.ibm.com/developerworks/xml/library/x-eleatt.html >>>> http://nedbatchelder.com/blog/200412/elements_vs_attributes.html >>>> http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf >>>> >>>> In particular, from the X12 Reference Model for XML Design: >>>> >>>> 7.2.5 Elements vs. Attributes >>>> Description: Often it is possible to model a data item as a child >>>> element or an >>>> attribute. >>>> >>>> Benefits of Using Elements >>>> >>>> -They are more extensible because attributes can later be added to >>>> them without >>>> affecting a processing application. >>>> -They can contain other elements. For example, if you want to >>>> express a textual >>>> description using XHTML tags, this is not possible if description >>>> is an >>>> attribute. >>>> -They can be repeated. An element may only appear once now, but >>>> later you may >>>> wish to extend it to appear multiple times. >>>> -You have more control over the rules of their appearance. For >>>> example, you can >>>> say that a product can either have a number or a productCode child. >>>> This is not >>>> possible for attributes. >>>> -Their order is significant if specified as part of a sequence, >>>> while the order >>>> of attributes is not. Obviously, this is only an advantage if you >>>> care about the >>>> order. >>>> -When the values are lengthy, elements tend to be more readable >>>> than attributes. >>>> >>>> >>>> Disadvantages of Using Elements >>>> >>>> -Elements require start and end tags, so are therefore more >>>> verbose. (NOTE: not >>>> all elements require a start and end tag — elements can be declare >>>> d in a single >>>> line.) >>>> >>>> Benefits of Using Attributes >>>> >>>> -They are less verbose. >>>> -Attributes can be added to the instance by specifying default >>>> values. Elements >>>> cannot (they must appear to receive a default value). >>>> -Attributes are atomic and cannot be extended and its existence >>>> should serve to >>>> remove any and all possible ambiguity of the element it describes. >>>> They are >>>> “adjectives” to the element “noun”. >>>> >>>> Disadvantages of Using Attributes >>>> >>>> -Attributes may not be extended by adding children, whereas a >>>> complex element >>>> may be extended by adding additional child elements or attributes. >>>> -If attributes are to be used in addition to elements for conveying >>>> business >>>> data, rules are required for specifying when a specific data item >>>> shall be an >>>> element or an attribute. >>>> >>>> >>>> Jason >>>> ________________________________________ >>>> From: [email protected] [[email protected]] On >>>> Behalf Of >>>> Paul Benedict [[email protected]] >>>> Sent: Friday, September 04, 2009 3:05 PM >>>> To: Maven Developers List >>>> Subject: Re: Re : non-xml poms in 3.x >>>> >>>> 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 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 [[email protected]] >>>>> 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: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> ------------------------------------------------------------------ >>>>>>> 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] >>>>> >>>>> >>>>> --- >>>>> ------------------------------------------------------------------ >>>>> 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] >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> --------------------------------------------------------------------- >> 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] >> > > 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]
