You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by nicolas de loof <ni...@apache.org> on 2008/02/10 10:34:18 UTC
proposal : make POM less verbose
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.
Re: proposal : make POM less verbose
Posted by Michael McCallum <gh...@apache.org>.
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 need to look at
the way they are using poms in the first place, appropriate use of
refactoring will help keep them clean and readable even in the current format
On Mon, 11 Feb 2008 07:17:00 Jason van Zyl wrote:
> 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-Feb-08, at 1: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.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people
> can fix bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Jason van Zyl <ja...@maven.org>.
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-Feb-08, at 1: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.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by nicolas de loof <ni...@apache.org>.
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 think it's possible to express
attribute XOR element in XSD).
The XML reader would then have to support both attributes and elements, with
ERROR handling when both are used.
Maybe it could also be combined with XMLWriter for converting to "classic"
POM when deploying to a repository, to ensure backward compatibility ?
Nico.
2008/2/10, Wendell Beckwith <wb...@gmail.com>:
>
> I see your +1000 and will raise you +5000 as this is really needed.
>
> Wb
>
>
> On Feb 10, 2008 8:08 AM, Arik Kfir <ar...@gmail.com> wrote:
>
> > As a long-time Maven user: a big +1000 from me :)
> >
> >
> > --
> >
> > Thanks,
> > Arik Kfir.
> >
>
Re: proposal : make POM less verbose
Posted by Wendell Beckwith <wb...@gmail.com>.
I see your +1000 and will raise you +5000 as this is really needed.
Wb
On Feb 10, 2008 8:08 AM, Arik Kfir <ar...@gmail.com> wrote:
> As a long-time Maven user: a big +1000 from me :)
>
>
> --
>
> Thanks,
> Arik Kfir.
>
Re: proposal : make POM less verbose
Posted by Arik Kfir <ar...@gmail.com>.
As a long-time Maven user: a big +1000 from me :)
On Feb 10, 2008 11:34 AM, nicolas de loof <ni...@apache.org> 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.
>
--
Thanks,
Arik Kfir.
Re: proposal : make POM less verbose
Posted by Jason van Zyl <ja...@maven.org>.
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 that situation
> completely unacceptable. I don't care if the parser is Java, Ruby or
> whatever. I do care that Maven controls the schema associated with
> all variations of the POM.
>
I don't think many average users are going to be able to do this and
if they did then they lose all benefit of what we're trying to
accomplish. Almost everything is "pluggable" in Maven but I doubt will
stray very far. If they do they have their own system and good luck to
them. I understand what you're saying.
> 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 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 magic they like.
>> I think a less verbose form of XML would be universally appreciated.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 care if the parser is Java, Ruby or whatever. I do
care that Maven controls the schema associated with all variations of
the POM.
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 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 magic they like. I think a less
> verbose form of XML would be universally appreciated.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Don Brown <mr...@twdata.org>.
Hmmm...what about a more simple solution that uses XSLT processing instructions?
<?xml-stylesheet type="text/xsl" href="myMavenPomFormat.xsl" ?>
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 new XML format
* The processing bit sit outside the XML document and is easily detected first
Disadvantages:
* Doesn't allow for fancy Groovy or whatever POMs
* Would make loading that POM a little slower (although really with
proper caching, it would be pretty quick)
This solution could probably be hacked up within a few hours and would
be completely optional and backwards compatible.
Don
On 2/11/08, Jason van Zyl <ja...@maven.org> 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 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 magic they like. I think a less
> verbose form of XML would be universally appreciated.
>
>
> On 10-Feb-08, at 1:11 PM, Ralph Goers wrote:
>
> > 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 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?
> >>
> > I wish it was that simple. There are hundreds of pre-existing poms
> > that you would need to be able to read, so it isn't just a case of
> > use one or the other. In a best case scenario you would need to use
> > your "new" parser for the new format and the "classic" for the old.
> > Now if folks start creating poms using all kinds of syntax the
> > situation will quickly get out of hand. To me, making this
> > pluggable is a recipe for disaster.
> >
> > Ralph
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> Three people can keep a secret provided two of them are dead.
>
> -- Unknown
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Paul Benedict <pb...@apache.org>.
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
Re: proposal : make POM less verbose
Posted by Brett Porter <br...@apache.org>.
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 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 magic they like. I think a
> less verbose form of XML would be universally appreciated.
>
>
> On 10-Feb-08, at 1:11 PM, Ralph Goers wrote:
>
>> 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 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?
>>>
>> I wish it was that simple. There are hundreds of pre-existing poms
>> that you would need to be able to read, so it isn't just a case of
>> use one or the other. In a best case scenario you would need to use
>> your "new" parser for the new format and the "classic" for the old.
>> Now if folks start creating poms using all kinds of syntax the
>> situation will quickly get out of hand. To me, making this
>> pluggable is a recipe for disaster.
>>
>> Ralph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> Three people can keep a secret provided two of them are dead.
>
> -- Unknown
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Jason van Zyl <ja...@maven.org>.
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 magic they like. I think a less
verbose form of XML would be universally appreciated.
On 10-Feb-08, at 1:11 PM, Ralph Goers wrote:
> 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 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?
>>
> I wish it was that simple. There are hundreds of pre-existing poms
> that you would need to be able to read, so it isn't just a case of
> use one or the other. In a best case scenario you would need to use
> your "new" parser for the new format and the "classic" for the old.
> Now if folks start creating poms using all kinds of syntax the
> situation will quickly get out of hand. To me, making this
> pluggable is a recipe for disaster.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Ralph Goers <Ra...@dslextreme.com>.
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
> 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?
>
I wish it was that simple. There are hundreds of pre-existing poms that
you would need to be able to read, so it isn't just a case of use one or
the other. In a best case scenario you would need to use your "new"
parser for the new format and the "classic" for the old. Now if folks
start creating poms using all kinds of syntax the situation will quickly
get out of hand. To me, making this pluggable is a recipe for disaster.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Tim O'Brien <to...@discursive.com>.
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 <to...@discursive.com> 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 <to...@discursive.com>:
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Wendell Beckwith <wb...@gmail.com>.
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. It kinda destroys the universal
understanding of Maven.
Wb
On Feb 10, 2008 11:01 AM, Tim O'Brien <to...@discursive.com> 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 <to...@discursive.com>:
> >>
> >> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: proposal : make POM less verbose
Posted by Tim O'Brien <to...@discursive.com>.
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 <to...@discursive.com>:
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by nicolas de loof <ni...@apache.org>.
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 to convert the POM to "classic"
element-based format.
Nico.
2008/2/10, Tim O'Brien <to...@discursive.com>:
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: proposal : make POM less verbose
Posted by Tim O'Brien <to...@discursive.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: proposal : make POM less verbose
Posted by Jason van Zyl <ja...@maven.org>.
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 relatively straight forward in collecting
something in the Wiki, and you can look historically at what Spring
did with their descriptors which is exactly what we're talking about.
Find out how they dealt with it.
I think most of your time will be spent with 2). Basically you just
need to ensure that the object model ends up being the same regardless
of what read/writer you generate and use.
Right now in the core the Xpp3Reader is hard-coded but in the CAP
branch I've already started working on figuring out how to figure out
the version of the POM being used and use that information to select
the right reader. But I think you're going to be busy with 1) and 2)
for a while.
I don't think mixed versions are wise. You use one version of the
other. Also I don't see scripting ever getting into the reader/
writers. The POM is data and for Maven proper I would never support
scripting in the POM. That's not to say sibling projects can't use
groovy builders, or ruby scripting. I think creating a attributed
based POM will be hard enough.
Once 1) and 2) are done we can talk about integrating it into the
core. But 1) and 2) can be completely done and tested before trying to
push it into the core. If you push this into the dashboard and design
proposals it's something I can bring up with the folks that show up to
the Maven day next week. I can show them your proposal whatever state
it is in next Friday to get some feedback for you.
On 10-Feb-08, at 1: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.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org