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