On 10-Feb-08, at 8:08 PM, Ralph Goers wrote:
I think you are missing my point. I have no problem with allowing a
more compact XML using attributes instead of elements. But the
minute you allow the parser to be pluggable you allow folks to start
inventing their own POM syntax. I would find
Hmmm...what about a more simple solution that uses XSLT processing instructions?
Then, Maven just has to detect that instruction when loading the XML,
and apply the stylesheet accordingly to get the standard Maven XML.
The advantages are:
* Very few coding changes for Maven
* Easy to plug in a
I think you are missing my point. I have no problem with allowing a more
compact XML using attributes instead of elements. But the minute you
allow the parser to be pluggable you allow folks to start inventing
their own POM syntax. I would find that situation completely
unacceptable. I don't ca
I wish we could turn nested tags into attributes. Spring has a "p" namespace
which is a very similar idea. If Maven isn't going to take advantage of
attributes, using them as alises for nested tag shortcuts seems reasonable.
Paul
The tools to do this are all in modello already. I'm experimenting
with a very basic conversion right now.
On 11/02/2008, at 8:38 AM, Jason van Zyl wrote:
There will be no choice but to walk in a few bytes of the POM,
determine the version and use the appropriate reader.
That said I don't
the current pom structure is very easy to edit in many editors...
attributes would make it a bit simpler in some circumstances but not
necessarily more readable
perhaps a pom to yaml printer plugin would help people to read it...
I would say that people who really want to change it probably nee
There will be no choice but to walk in a few bytes of the POM,
determine the version and use the appropriate reader.
That said I don't think anything language specific a la ruby or groovy
has any place in Maven proper. Lots of room for side projects that use
the embedder and whatever other
Tim O'Brien wrote:
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
Also look here for previous discussions:
http://docs.codehaus.org/display/MAVEN/Terse+POM+Syntax+-+Design+Discussion
http://docs.codehaus.org/display/MAVEN/POM+Loading+and+Building
You might want to start by looking at those and cleaning those up.
Sifting out anything that's in JIRA.
On 10-F
This is not a trivial task so I would suggest the following:
1) find out what the ideal representation would be
2) determine what would be needed in modello to generate the reader/
writer (this will actually be a lot of work)
3) try the changes out in the core
Dealing with 1) should be relativ
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 cur
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
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 custo
Using attributes in place of XML elements is not revolutionary. I don't
speak here about writting POMs in 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
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 pl
I'm sure there is lot's of interest for some XML "compression"
the main discution is HOW ?
AFAIK this would require some changes in Modello to generate a more flexible
XML Reader.
The schema generation would not be too complex : generate both elements and
attributes for simple types (I don't thin
I see your +1000 and will raise you +5000 as this is really needed.
Wb
On Feb 10, 2008 8:08 AM, Arik Kfir <[EMAIL PROTECTED]> wrote:
> As a long-time Maven user: a big +1000 from me :)
>
>
> --
>
> Thanks,
> Arik Kfir.
>
As a long-time Maven user: a big +1000 from me :)
On Feb 10, 2008 11:34 AM, nicolas de loof <[EMAIL PROTECTED]> 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
>
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
element
19 matches
Mail list logo
