Any idea when this might be, approximately?
On Sep 7, 2009, at 1:36 AM, Jason van Zyl wrote: > No it's not available and won't be until I'm finished a fully working > beta. > > On 2009-09-07, at 1:42 AM, Christian Edward Gruber wrote: > >> Is that prototype available? I'd love to see it. >> >> Christian >> >> On 2009-09-06, at 18:53 , Jason Chaffee wrote: >> >>> 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 [stephen.alan.conno...@gmail.com] >>>>> 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 <henr...@yahoo.fr> 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 <jason.chaf...@zilliontv.tv> >>>>>>> À : Maven Developers List <dev@maven.apache.org> >>>>>>> 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 [jason.chaf...@zilliontv.tv] >>>>>>> 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: paulus.benedic...@gmail.com [paulus.benedic...@gmail.com] >>>>>>> On >>>>>>> Behalf Of >>>>>>> Paul Benedict [pbened...@apache.org] >>>>>>> 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 [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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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 >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>> >> >> Christian Edward Gruber >> e-mail: christianedwardgru...@gmail.com >> weblog: http://www.geekinasuit.com/ >> >> >> --------------------------------------------------------------------- >> 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
