On Feb 10, 2008, at 11:14 AM, Wendell Beckwith wrote:
Tim,
I see where you're going and in general I agree with you as I think
most
software should be extensible to handle unknown environments and
unique
situations.
However, I think the biggest bang for buck is to fix/enhance
the current one way and then add pluggability for POM parser
substitution if
it is really needed. The 1 negative that I see in POM parser
substitution
is that if a user is use to "classic" POM files and sees an
"enhanced" POM
file then they will likely still be able to grok what's going on.
However,
a user seeing a groovy, jruby or Joe Blow's domain specific language
POM
file will be in a WTF situation.
People will use whatever implementation they feel like using. I'd
propose that you start by shipping Maven with two:
1. Classic - the way it works now
2. Reduced XML - the thing that Nicolas proposed
If someone wants to ship an implementation that understands something
like:
http://www.coderoshi.com/2007/08/maven-less-ugly.html
If people start using it, and there is a demand to add native support
for someone's format, then you can add it in later.
As long as it contains the same info, no more, no less, than the POM
you have now. What's the damage? Does Eric's YAML break the
Universal Understanding, or does it provide another path for users who
might not want to start at XML even if it is different?
Wb
On Feb 10, 2008 11:01 AM, Tim O'Brien <[EMAIL PROTECTED]> wrote:
On Feb 10, 2008, at 10:57 AM, nicolas de loof wrote:
Using attributes in place of XML elements is not revolutionary. I
don't
speak here about writting POMs in groovy !
That's the difference, I do. I think people should have the
opportunity to replace the parser entirely and write custom
implementations. Class POM + something more like what you propose.
But I also don't think the door should be closed for someone to come
along and write a parser that can read something like YAML or Groovy.
This is just about better use of XML, it requires only a "tweak" of
the
Xpp3Parser to handle attributes the same way it handles nested
elements, and
maybe to change the install/deploy to convert the POM to "classic"
element-based format.
The problem here is that there is one way to parse a model, changing
that one way to a different way isn't the fix. The fix is to provide
more than one implementation.
Nico.
2008/2/10, Tim O'Brien <[EMAIL PROTECTED]>:
Nicolas,
I agree that POM verbosity is a problem, but I also think that a
lot
of people on this list are not going to want to introduce
revolutionary changes to POM structure without being convinced
(as we
are) that it is a problem.
The first step to this would be to add the ability to plugin in
another parser implementation. Abstract both the pom and settings
parsing from the Xpp3 stuff generated by modello, and make the Xpp3
parsers the default implementation. At that point, it would be
easier to generate alternative parsers or preprocessors (like what
Redmond did with YAML). What can't change is the infoset of the
current POM, the current POM structure can't change because of
backwards compatibility, the POM that is generated in a repository
cannot change, but the format that people use to manage a project.
That should be pluggable and customizable, but any change
introduced
can't break the current model.
But, I'm not optimisitc it is going to happen unless someone just
does
it and writes a ranting blog entry about it.
Tim O'Brien
On Feb 10, 2008, at 3:34 AM, nicolas de loof wrote:
Hello,
Maven detractors blam maven POM.xml to become huge XML files even
for
simple tasks.
Considering the comparison with ant, the latest use XML attributes
an few
XML elements, making tasks declaration consise.
Could we introduce a new XML schema (for maven 2.1) to support
simple types
elements as attributes, maybe using namespaces :
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.codehaus.mojo</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
</project>
... could be written :
<project modelVersion="4.0.0"
groupId="org.codehaus.mojo" artifactId="my-project"
version="1.0">
</project>
We could use namespaces to avoid colision in maven schemas, and
support a mix of elements and attributs :
<project m2:groupId="org.codehaus.mojo" m2:artifactId="my-project"
m2:version="1.0">
<modelVersion>4.0.0</modelVersion>
</project>
The previous examples are just to fix the principle. Declaring
dependencies and plugins configuration could become really consice
and
enhance readability.
Nico.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
