The extension would be required to support the new feature behind the namespace tags.
My idea is to separate the modelVersion (maven-model.jar version in use) and the POM XML structure, that could use some custom parsing / post-processors, like the example profile desactivation. 2008/5/18 Bryon Jacob <[EMAIL PROTECTED]>: > I wrote a kinda lengthy blog post about doing this sort of thing: > > > http://freedomandbeer.com/posts/extensible-xml-with-xml-namespaces-and-relaxng > > RelaxNG is a fantastic language for specifying schemas for XML - the > grammar notation is very natural to write in. Allowed elements are > specified using "name classes", and you can perform set arithmetic over > those classes to achieve some amazing results for extensibility, by > delegating validation of extension elements to the author of the extensions, > while retaining the ability to assert the validity of the core document > structure. > > If I understand the problem that you're trying to solve here, it is exactly > analogous to the example in my blog post. I think you would probably > structure your xml somewhat differently than below - you define the > "profile" namespace prefix on the <extension> element, but since the profile > isn't a child of that element, the declaration doesn't carry through. For > your goals here, I don't even think the <extension> element buys you > anything -- what you really want to do, it seems, is change the core Maven > schema to allow arbitrary extensions to a project's XML, as long as they are > partitioned into a new namespace - rewriting your example XML: > > <project xmlns="http://maven.apache.org/POM/4.0.0";> > ... > <profile xmlns:profile=" > http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation";> > > <activation> > <activeByDefault>true</activeByDefault> > </activation> > <profile:deactivation> > <profile:os> > <profile:name>Windows 98</profile:name> > <profile:os> > </profile:deactivation> > </profile> > ... > </project> > > Using RelaxNG, you could write the rule for the <profile> element to allow > any element NOT in the maven namespace to be included: > > PROFILE = > element maven:profile { > element maven:activation { > element maven:activeByDefault { xsd:boolean} > } > | ANY_EXT_ELEMENT* > } > ANY_EXT_ELEMENT = > element * - maven:* { > attribute * { text }*, > ( text* & ANY_EXT_ELEMENT* )* > } > > And then, you could declare a RelaxNG grammar to parse a "project with > profile enancements" document like: > > include "maven.rnc" { > ANY_EXT_ELEMENT = > element * - (maven:* | profile:*) { > attribute * { text }*, > ( text* & ANY_EXT_ELEMENT* )* > } > | DEACTIVATION > } > DEACTIVATION = > element profile:deactivation { > element profile:os { > element profile:name { text } > } > } > > Like I said, there's a much more detailed, and analogous, example at the > link above. hope this helps! > > - Bryon > > > > On May 16, 2008, at 1:53 PM, nicolas de loof wrote: > > Hello, >> >> many thread on this list makes proposal for some changes in the POM.xml >> format, to be included in 4.1.0 modelVersion. >> >> Could we use XML namespaces to support progressive enhancements ? Based on >> this, proposal for new features could be added to maven, using an >> <extension> to support the new schema, without requirement to wait for >> next >> major version to include POM structure changes. >> >> example : considering the recent proposal for profiles enhancements >> >> http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation >> >> <profile> >> <activation> >> <activeByDefault>true</activeByDefault> >> </activation> >> <deactivation> >> <os> >> <name>Windows 98</name> >> </os> >> </deactivation> >> </profile> >> Could be rewritten : >> >> <extensions> >> <extension xmlns:profile= >> >> http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation >> >>> >>> <groupId>org.apache.maven.proposals</groupId> >> <artifactId>profile-enhancements</artifactId> >> </extension> >> <extensions> >> >> <profile> >> <activation> >> <activeByDefault>true</activeByDefault> >> </activation> >> <profile:deactivation> >> <profile:os> >> <profile:name>Windows 98</profile:name> >> </profile:os> >> </profile:deactivation> >> </profile> >> This can be compared with namespace support in Springframework context >> files >> : adding a new custom namespace allow to make the configuration less >> verbose >> or more powerfull, with no requirement to change the base XML model. >> >> Nicolas >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
