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 <[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] > >
