FWIW, I think as long as we have a standard format for POMs on a
single remote repository, it doesn't hurt to accommodate all comers
WRT format.
XML is okay for developers familiar with it to read, but it was
always intended to be rendered in some way. If we had rendering tools
to give the user a decent view on the POM, all of these arguments
would go away, since we could just provide additional renderers along
with the different parsers.
Also, if we're going to accommodate multiple XML formats (element-
oriented vs. attribute-oriented) would it make more sense to give a
hint of which format we're using via processing instruction at the
top or something similar? If we do this, there could be 2 XML-based
parsers, or 2000...as long as the shared data in the remote
repository has a standard format, what's the difference? We can
control the standard format on the central repository, for one thing,
and definitely make sure it's as consumable as possible for older
Maven versions. Others running their own internal repositories will
have their own concerns WRT POM format, and can set their internal
policy as they see fit.
-john
On Feb 12, 2008, at 10:55 AM, Tim O'Brien wrote:
On Feb 12, 2008, at 9:34 AM, Gilles Scokart wrote:
-----Original Message-----
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: mardi 12 février 2008 16:03
To: Maven Developers List
Subject: Re: An Attribute Based POM
On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:
For example, we'd can group groupId/artifactId/version into one
attribute
like this:
<dependency artifact="org.apache.maven:maven-project:
2.0.8" [...] />
Please don't do this. This would require another parsing step after
the XML
parsing and introduces further error sources. Use XML to structure
the data,
not some proprietary format. Third-party tools dealing with the POM
will
also appreciate a proper/pure XML representation of the project
model.
Consider for instance the pain such string aggregates would cause
for XSLT
processing of the POM. Merging different pieces of data into a
single string
is in general a bad idea.
Couldn't disagree more. Certain data has a native format.
Consider
something like a 24 hour time. Is:
<time>23:22:22.003</time>
an "undue burden" on different parsers? No, this is reasonable.
This would be unreasonable:
<time hour="23" minute="22" second="22" millis="003"/>
The idea that we have to design data around parsers means that you
sacrifice usability and readability.
I'd take it one step further than Emmanuel:
<dependencyGroup root="org.apache.maven">
<dependency artifact="maven-project:2.0.8"/>
<dependency artifact="continuum:continuum-model:1.1"/>
</dependencyGroup>
Should be:
<dependGroup root="org.apache.maven">
maven-project:2.0.8
continuum:continuum-model:1.1
</dependGroup>
XSLT can tokenize strings just fine.
Than why to use XML? Why not have simple text?
Giles, why not simple text? People have already been working with
POMs in alternative formats that don't involve XML at all. I
guess the real question here is, why would it disturb people so
much if someone had an alternative format for a POM for every day
use, but when they published to a repo it used the standard format.
No seriously, keep the organisation and artefact separated from
the version. There are plenty of use case that needs to
identify them separately (like the management of the conflict, the
management of the dependent projects).
If you really want something more textual, I suggest you look at
buildr. It give you something like this :
AXIOM = group("axiom-api", "axiom-impl", "axiom-dom",
:under=>"org.apache.ws.commons.axiom", version=>"1.2.4")
AXIS2 = "org.apache.axis2:axis2:jar:1.2"
OPENJPA = ["org.apache.openjpa:openjpa-all:jar:0.9.7",
"net.sourceforge.serp:serp:jar:1.12.0"]
AXIS_OF_WS = [AXIS2, AXIOM]
compile.with OPENJPA, AXIS_OF_WS
Why not? It might be user friendly (for some users...). But I
don't want to see this in a repository. IMO, XML is
much better.
No one is talking about modifying the repository, the repository
should contain one format of POM, but there is no reason why there
cannot be a diversity of implementations. Oh wait, people here
think it would screw up "Universal Understanding".
:-)
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
