You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Julien HENRY <he...@yahoo.fr> on 2009/09/04 21:43:20 UTC
Re : non-xml poms in 3.x
Hi,
> De : Jason van Zyl <jv...@sonatype.com>
> [...]
> Personally, I don't see a different XML format being any great usability gain.
> With editors and IDEs it's not that bad and you also have to consider what
> people are already accustom to. I honestly think another XML format would just
> be confusing and not really buy us a whole lot. The debate of clarity is
> subjective. I like the elements, you like attributes the debate could go on
> forever but as of today we got what we got.
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.
So a big +1 to Jason.
>
> On 2009-09-04, at 5:21 PM, Christian Edward Gruber wrote:
>
> > Hi all,
> >
> > So I saw Jason's highlights of 3.x future plans, and decoupling POMs from
> format. We're starting to use m3 on an open-source little project at Google,
> and the main problem people have with Maven has been the gawd-awful (not my
> words) of the xml format. I used the maven-yamlpom-plugin to simulate this, by
> having a wrapper script that syncs a pom.yml with the pom.xml before executing
> any other maven command, but it's a hack, and I'd rather (since we're already
> using 3 anyway) try to help us get to the point where i can just have a pom.yml
> and have maven (and its various integrations) understand it. So...
> >
> > 1. Any update on where that is - I haven't been following svn commits lately,
> but I'd like to start re-syncing wtih m3 progress
> > 2. Any suggestions on where the seams are around pom building so I can start
> looking at how to provide an alternative format
> > 3. Anyone already working on this specific thing?
> >
> > cheers,
> > Christian.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my [rhymes with myPod] ;-)
On 5 Sep 2009, at 19:58, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 2009-09-05, at 2:45 PM, Stephen Connolly wrote:
>
>> 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.
>>
>
> +1
>
> It's makes tons of things harder because lots of people have bound
> directly to the XML model and not the object model. This isn't good
> but that's what happens.
I'm not saying I'm happy about having to go direct to the XML in v-m-
p...
the primary reasons are:
1. we are rewriting the pom, and we want to ensure that any existing
formatting is preserved
2. there are some hacks within maven apis that force us to confirm via
the pom directly
now once I get xevpp.codehaus.org finished, that will remove the
issues with #1
#2 is about seeing what the 3.x API "features" are
-Stephen
>
>> Sent from my [rhymes with myPod] ;-)
>>
>> On 5 Sep 2009, at 12:00, Julien HENRY <he...@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 <ja...@zilliontv.tv>
>>>> À : Maven Developers List <de...@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.chaffee@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 dec
>>>> lared 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.benedictus@gmail.com [paulus.benedictus@gmail.com]
>>>> On Behalf Of
>>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ---
>>>>>>> ---------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-05, at 2:45 PM, Stephen Connolly wrote:
> 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.
>
+1
It's makes tons of things harder because lots of people have bound
directly to the XML model and not the object model. This isn't good
but that's what happens.
> Sent from my [rhymes with myPod] ;-)
>
> On 5 Sep 2009, at 12:00, Julien HENRY <he...@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 <ja...@zilliontv.tv>
>>> À : Maven Developers List <de...@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.chaffee@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
>>> declared 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.benedictus@gmail.com [paulus.benedictus@gmail.com] On
>>> Behalf Of
>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
Ok. Thanks.
Christian
On 2009-09-07, at 04:36 , 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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com
>>>>>>> [paulus.benedictus@gmail.com] On
>>>>>>> Behalf Of
>>>>>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Christian Edward Gruber
>> e-mail: christianedwardgruber@gmail.com
>> weblog: http://www.geekinasuit.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-08, at 3:11 AM, Brett Porter wrote:
> On 08/09/2009, at 8:06 AM, Jason Chaffee wrote:
>
>> I understand that you probably don't want to commit to a date or
>> cause
>> undue expectations from anyone on this list, so let me ask it in a
>> slight differently way.
>>
>> Do you think it "might" be possible that we see a beta 3.x in 2009?
>>
>> One reason I ask is because I would like to schedule some time in
>> late
>> 2009 for 3.x investigation , but if you know that it will not be
>> available by the end of 2009 then there is no reason to get into our
>> schedule.
>
>
> My understanding is that the documents now going into the wiki will
> this time get locked down sometime soon, a goal will be set that all
> the developers agree to, and the beta will be ready when the list of
> things to do reaches zero. After 3 years of moving targets, it's
> certainly time. That's maybe not a date, but it should be enough for
> you to gauge whether it's happening or not.
>
> Jason (van Zyl), is that the plan?
>
When we can find no errors in 2.x projects in an 8 week window of
aggressive sampling I think we'll be able to call that 3.0.
> I'm wondering if we should call this the Snow Maven release given
> the goals seem similar to something else... :)
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Brett Porter <br...@apache.org>.
On 08/09/2009, at 8:06 AM, Jason Chaffee wrote:
> I understand that you probably don't want to commit to a date or cause
> undue expectations from anyone on this list, so let me ask it in a
> slight differently way.
>
> Do you think it "might" be possible that we see a beta 3.x in 2009?
>
> One reason I ask is because I would like to schedule some time in late
> 2009 for 3.x investigation , but if you know that it will not be
> available by the end of 2009 then there is no reason to get into our
> schedule.
My understanding is that the documents now going into the wiki will
this time get locked down sometime soon, a goal will be set that all
the developers agree to, and the beta will be ready when the list of
things to do reaches zero. After 3 years of moving targets, it's
certainly time. That's maybe not a date, but it should be enough for
you to gauge whether it's happening or not.
Jason (van Zyl), is that the plan?
I'm wondering if we should call this the Snow Maven release given the
goals seem similar to something else... :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
I understand that you probably don't want to commit to a date or cause
undue expectations from anyone on this list, so let me ask it in a
slight differently way.
Do you think it "might" be possible that we see a beta 3.x in 2009?
One reason I ask is because I would like to schedule some time in late
2009 for 3.x investigation , but if you know that it will not be
available by the end of 2009 then there is no reason to get into our
schedule.
kind regards,
Jason
On Sep 7, 2009, at 1:41 PM, Jason van Zyl wrote:
> No.
>
> On 2009-09-07, at 10:40 PM, Jason Chaffee wrote:
>
>> 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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>>>>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com
>>>>>>>>> [paulus.benedictus@gmail.com]
>>>>>>>>> On
>>>>>>>>> Behalf Of
>>>>>>>>> Paul Benedict [pbenedict@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
>>>>>>>>>> [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> Christian Edward Gruber
>>>> e-mail: christianedwardgruber@gmail.com
>>>> weblog: http://www.geekinasuit.com/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
No.
On 2009-09-07, at 10:40 PM, Jason Chaffee wrote:
> 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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>>>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com]
>>>>>>>> On
>>>>>>>> Behalf Of
>>>>>>>> Paul Benedict [pbenedict@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
>>>>>>>>> [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Christian Edward Gruber
>>> e-mail: christianedwardgruber@gmail.com
>>> weblog: http://www.geekinasuit.com/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com]
>>>>>>> On
>>>>>>> Behalf Of
>>>>>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Christian Edward Gruber
>> e-mail: christianedwardgruber@gmail.com
>> weblog: http://www.geekinasuit.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com]
>>>>>> On
>>>>>> Behalf Of
>>>>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Christian Edward Gruber
> e-mail: christianedwardgruber@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com] On
>>>>> Behalf Of
>>>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> ------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> ------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com] On
>>>> Behalf Of
>>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com] On
>>> Behalf Of
>>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> ------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Re : Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
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.
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.connolly@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 <he...@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 <ja...@zilliontv.tv>
>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com] On
>> Behalf Of
>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : Re : non-xml poms in 3.x
Posted by Stephen Connolly <st...@gmail.com>.
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 <he...@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 <ja...@zilliontv.tv>
>> À : Maven Developers List <de...@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.chaffee@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.benedictus@gmail.com [paulus.benedictus@gmail.com] On
>> Behalf Of
>> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re : Re : non-xml poms in 3.x
Posted by Julien HENRY <he...@yahoo.fr>.
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 <ja...@zilliontv.tv>
> À : Maven Developers List <de...@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.chaffee@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 declared 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.benedictus@gmail.com [paulus.benedictus@gmail.com] On Behalf Of
> Paul Benedict [pbenedict@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
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.chaffee@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 declared 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.benedictus@gmail.com [paulus.benedictus@gmail.com] On Behalf Of Paul Benedict [pbenedict@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 <ja...@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
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 declared 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.benedictus@gmail.com [paulus.benedictus@gmail.com] On Behalf Of Paul Benedict [pbenedict@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 <ja...@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
Or even just artifacts in compressed form
<dependency artifact="com.google:guice:1.3">
equates to:
<dependency>
<artifactId>guice</artifactId>
<groupId>com.google</groupId>
<version>1.3</version>
</dependency>
<plugin artifact=":maven-compiler-plugin:1.2">
implies (after short resolution>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>1.2</version>
</plugin>
Christian.
On Sep 4, 2009, at 6:05 PM, Paul Benedict wrote:
> 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.chaffee@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Paul Benedict <pb...@apache.org>.
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 <ja...@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 [christianedwardgruber@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: Re : non-xml poms in 3.x
Posted by Jason Chaffee <ja...@zilliontv.tv>.
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 [christianedwardgruber@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
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.
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.
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 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).
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
Ok. Sounds workable.
Christian.
On Sep 8, 2009, at 4:00 AM, Jason van Zyl wrote:
>
> On 2009-09-08, at 9:49 AM, Christian Edward Gruber wrote:
>
>> 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)
>>
>
> These are not going to be discovered. You are going to have to
> support hooking in your format. Autodiscovery implies support on our
> side and that's not going to happen. That's not a trivial system to
> make work properly. I've tried and it's exactly the can of worms I'm
> talking about. It's a few lines of code on your side. So again, the
> onus is going to be on you to support your version of Maven that
> works with a given POM format. There will be no autodiscovery
> mechanism in 3.x.
>
>> 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.
>
> Neither did I, you misread. M2Eclipse won't even be able to read the
> POM. These tools use their own parsers which integrate into the
> given platform. In M2Eclipse we actually use EMF, not Maven's
> internal parser. I'm sure Netbeans and IDEA have similar mechanisms.
> So there isn't parity in the tooling either. The autodiscovery
> happening in the core and then being magically picked up in tooling
> is a pipe dream.
>
>> 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.
>>
>
> Ultimately in 3.x you'll be able to write your own front-end parser,
> extend or overwrite a Guice wiring to put in what you like and then
> you're ready to go. Or you could also make the autodiscovery
> mechanism you talked about and wire that in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-08, at 9:49 AM, Christian Edward Gruber wrote:
> 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)
>
These are not going to be discovered. You are going to have to support
hooking in your format. Autodiscovery implies support on our side and
that's not going to happen. That's not a trivial system to make work
properly. I've tried and it's exactly the can of worms I'm talking
about. It's a few lines of code on your side. So again, the onus is
going to be on you to support your version of Maven that works with a
given POM format. There will be no autodiscovery mechanism in 3.x.
> 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.
Neither did I, you misread. M2Eclipse won't even be able to read the
POM. These tools use their own parsers which integrate into the given
platform. In M2Eclipse we actually use EMF, not Maven's internal
parser. I'm sure Netbeans and IDEA have similar mechanisms. So there
isn't parity in the tooling either. The autodiscovery happening in the
core and then being magically picked up in tooling is a pipe dream.
> 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.
>
Ultimately in 3.x you'll be able to write your own front-end parser,
extend or overwrite a Guice wiring to put in what you like and then
you're ready to go. Or you could also make the autodiscovery mechanism
you talked about and wire that in.
> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Stephen Connolly <st...@gmail.com>.
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 <ch...@gmail.com>
> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Jason van Zyl <jv...@sonatype.com>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Christian Edward Gruber <ch...@gmail.com>.
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." ;-)
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.
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.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Ralph Goers <ra...@dslextreme.com>.
On Sep 7, 2009, at 6:19 PM, Brett Porter wrote:
>
> On 05/09/2009, at 6:25 AM, 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.
>
> Agreed - though I think it's the "optional" part that is bad.
>
> Taking all the learnings and improving the format and making that
> the default should be a possibility. I'd want something very
> familiar, easy to recognise - the model is still the same, but the
> format might be different. Developers can learn those changes and
> their group can still standardise on one format, one version of
> Maven. The repository format can be standardised across versions and
> doesn't need to match (see other thread). Tools is the biggest
> problem - that's where "optional" hurts most. They can adapt and
> migrate but widening the options they need to work with other than
> for a finite set of versions of Maven is unreasonable.
Since we are on the topic of the pom format....
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.
This has been a rather long thread so I may have missed it but can
someone please summarize the current state?
Also, I brought up a long, long time ago changes I wanted to see made
in artifact resolution. It was recommended that that be held off until
a later beta phase. I still would like to see those changes
introduced as I still consider the way maven does artifact resolution
solely by version number to be inadequate. While maven 3 would still
be able to process pom's with this information added, maven 2 would
not. If we decide to make these kinds of changes it would be great to
add something to 2.x to allow it to ignore the extra info.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Brett Porter <br...@apache.org>.
On 05/09/2009, at 6:25 AM, 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.
Agreed - though I think it's the "optional" part that is bad.
Taking all the learnings and improving the format and making that the
default should be a possibility. I'd want something very familiar,
easy to recognise - the model is still the same, but the format might
be different. Developers can learn those changes and their group can
still standardise on one format, one version of Maven. The repository
format can be standardised across versions and doesn't need to match
(see other thread). Tools is the biggest problem - that's where
"optional" hurts most. They can adapt and migrate but widening the
options they need to work with other than for a finite set of versions
of Maven is unreasonable.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re : non-xml poms in 3.x
Posted by Brian Fox <br...@infinity.nu>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org