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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
