In the very specific case of groupId/artifactId/version pattern which is
currently very verbose I would tend to agree to allow shorter syntax using
attributes instead of elements.
<dependency groupId="" artifactId="" version="" classifier="" scope=""/>
<plugin groupId="" artifactId="" version="">
<configuration>
...
</configuration>
</plugin>
This is not what I consider a "big" change for endusers.
Still my 2 cents.
Regards,
Julien
----- Message d'origine ----
> De : Jason Chaffee <jason.chaf...@zilliontv.tv>
> À : Maven Developers List <dev@maven.apache.org>
> Envoyé le : Samedi, 5 Septembre 2009, 1h00mn 02s
> Objet : RE: Re : non-xml poms in 3.x
>
> FYI, I know that in the past Resin supported both Elements and attributes in
> it's config XML. It was really neat. If you preferred one over the other,
> you
> could use it. Don't know if it is still that way though.
>
> Jason
> ________________________________________
> From: Jason Chaffee [jason.chaf...@zilliontv.tv]
> Sent: Friday, September 04, 2009 3:27 PM
> To: Maven Developers List
> Subject: RE: Re : non-xml poms in 3.x
>
> I like the idea of having some things as attributes.
>
> See the following links on information on when to use attributes and when to
> use
> elements.
>
> http://www.ibm.com/developerworks/xml/library/x-eleatt.html
> http://nedbatchelder.com/blog/200412/elements_vs_attributes.html
> http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf
>
> In particular, from the X12 Reference Model for XML Design:
>
> 7.2.5 Elements vs. Attributes
> Description: Often it is possible to model a data item as a child element or
> an
> attribute.
>
> Benefits of Using Elements
>
> -They are more extensible because attributes can later be added to them
> without
> affecting a processing application.
> -They can contain other elements. For example, if you want to express a
> textual
> description using XHTML tags, this is not possible if description is an
> attribute.
> -They can be repeated. An element may only appear once now, but later you may
> wish to extend it to appear multiple times.
> -You have more control over the rules of their appearance. For example, you
> can
> say that a product can either have a number or a productCode child. This is
> not
> possible for attributes.
> -Their order is significant if specified as part of a sequence, while the
> order
> of attributes is not. Obviously, this is only an advantage if you care about
> the
> order.
> -When the values are lengthy, elements tend to be more readable than
> attributes.
>
>
> Disadvantages of Using Elements
>
> -Elements require start and end tags, so are therefore more verbose. (NOTE:
> not
> all elements require a start and end tag — elements can be 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.benedic...@gmail.com [paulus.benedic...@gmail.com] On Behalf Of
> Paul Benedict [pbened...@apache.org]
> Sent: Friday, September 04, 2009 3:05 PM
> To: Maven Developers List
> Subject: Re: Re : non-xml poms in 3.x
>
> Yes, the XML is verbose, and tooling helps but I think most people write it
> by hand. The only evolutionary change I support is the ability to specify
> simple nested elements as attributes.
>
> Paul
>
> On Fri, Sep 4, 2009 at 4:40 PM, Jason Chaffee wrote:
>
> > For what it is worth, I have heard many complaints either about using XML
> > and/or about the current structure of the XML as well. I have heard this
> > from developers I have worked with and I have read some blogs about this
> > too. I can't tell you where those blogs are now because I pretty much
> > dismissed them as I like using XML myself.
> >
> > Jason
> > ________________________________________
> > From: Christian Edward Gruber [christianedwardgru...@gmail.com]
> > Sent: Friday, September 04, 2009 2:29 PM
> > To: Maven Developers List
> > Subject: Re: Re : non-xml poms in 3.x
> >
> > Who said anything about a reasonable person? :) I don't have such a
> > hatred - I'm quite used to it, but it has come up in nearly every
> > client in the last 3 years - not as a final or deal-breaking barrier
> > to adoption, but a barrier nonetheless.
> >
> > I'm happy to support it - I just need a seam or hook where I can
> > provide something that pre-processes before the maven run to generate
> > the pom.xml. Maven itself doesn't need to support the alternate
> > format at all. If it could be something that was auto-detected as
> > well (or at worst, put into a settings.xml) then that'd be great.
> > Essentially I'm doing that now with the maven-yamlpom-plugin... it's
> > just that I have to do a separate run because it modifies the pom.xml,
> > and so maven fails on the first sync because the pom was modified.
> >
> > In a pinch, this can all be handled with shell scripts wrapping maven,
> > but I'd prefer to have a cleaner place to integrate.
> >
> > Christian.
> >
> > On Sep 4, 2009, at 5:12 PM, Jason van Zyl wrote:
> >
> > >
> > > On 2009-09-04, at 10:59 PM, Christian Edward Gruber wrote:
> > >
> > >> So I agree that it is a valid concern, and there needs to be a
> > >> canonical format (which will probably be XML) which all artifacts
> > >> are saved as - but in my source tree, it should be entirely
> > >> possible to have an alternate way to specify, since often I've
> > >> found that XML-hatred is a barrier to Maven adoption in some firms.
> > >>
> > >
> > > I have not found this to be a concern. There's lots of other things
> > > that are barrier but the XML has honestly never come up in any
> > > conversations I've had.
> > >
> > >> You should always be able to get the pom.xml... help:canonical-pom
> > >> would be a decent way to quickly do it, and artifacts should be
> > >> published that way - but a Project is an object, and alternate
> > >> serializations shouldn't be a problem.
> > >
> > > Therein lies the problem, the only real canonical form is the object
> > > model. With 3 XML formats which one is the canonical format? The
> > > first one?
> > >
> > >>
> > >> I would, also as an evangelist and implementor of build systems in
> > >> companies, encourage that a company standardize on a format, but if
> > >> that company wants to use YAML, or some other terser, more human
> > >> readable format for the pom, then I'm good with that.
> > >
> > > I'm not. Again this falls into my category of "if you want it that
> > > way, you support it." A company can standardize on whatever it
> > > wants, but I'm not going to hide the real cost of that. We may
> > > ultimately decide it's not worth it having another XML format. There
> > > are a lot more things in 3.0 that interest me then another XML format.
> > >
> > >>
> > >> I used to feel more like you, Brian, but for the sheer intensity of
> > >> hatred of XML out there (as a format for human-maintained source).
> > >>
> > >
> > > Again, I've not witnessed any XML hatred or that being a
> > > justification by a reasonable person not to use Maven.
> > >
> > >> The problem you're describing about one project using one and
> > >> another using a different one - that's no different than one
> > >> project deciding to use a different set of integration test plugins
> > >> (invoker vs. shitty) and confusing the noobs. The bottom line is
> > >> that you're not going to be able to constraint people from going
> > >> for the "new thing" and messing up the inexperienced, so providing
> > >> sane defaults with lots of room to customize is the best option, in
> > >> my view.
> > >>
> > >> Christian.
> > >>
> > >>
> > >> On Sep 4, 2009, at 4:25 PM, Brian Fox wrote:
> > >>
> > >>>> Just my 2 cents as a Maven evangelist in a big private company.
> > >>>> Even if
> > >>>> Maven is around for years now, basic endusers just start to get
> > >>>> accustomed to pom.xml and Maven philosophy (really! people are
> > >>>> far slowest to change than in OpenSource project team).
> > >>>>
> > >>>> Please, please don't mess everything. Small additions are fine,
> > >>>> but I think a new format is a bad idea even if it is optional.
> > >>>> One of advantage of Maven is standardization across all our
> > >>>> projects. If there are several format allowed, some projects will
> > >>>> start using new one when others are still using the former and it
> > >>>> will lead to a total mess.
> > >>>>
> > >>> That's my main concern as well to be honest.
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >>> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > > ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder, Apache Maven
> > > http://twitter.com/jvanzyl
> > > http://twitter.com/SonatypeNexus
> > > http://twitter.com/SonatypeM2E
> > > ----------------------------------------------------------
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
