I have one specific request for new POM model. <resources> element should allow the combine attribute. I am fine with the same behavior and names that are on plugin configuration elements.
<resources combine.self="override"> Above construct would allow switching resource folders with profiles, instead of default merging. Can anyone add it to the wiki [1]? Thanks. To discuss on the topics in the wiki: Namespaces seem to be a good idea with lot of benefits. Also hard to pass through. Attributes are easy pick. POM4 POM5 idea is ok, but only once. POM5 should deal with extensibility inside. Sadly, widely used XML Schema kills the X and forces ugly nesting. [1] https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model# > > A general theme of these comments is, 'and what are we going to put in > our new pom version?' > > I didn't go there in my writeup, since I was concerned with the > mechanics of 'how do we have a new POM *at all*'. But I see the point; > we can't make a new pom model every week, so we need to combine a > substantial list of proposed enhancements. > > Perhaps other could add more wiki content to start this? > > When I think about this, I find myself wishing that we could invent a > middle ground between 'no changes at all' and 'a new major version.' > > In the same way that individual plugins can add new <configuration/> > elements any time, I'd like to enhance my overall proposal to include > a section on 'future-proofing' the next schema rev by adding a few > judicious <xs:any/> specifications and documenting some conventions > for their use. In other words, as of 'pom5', any tool that reads a POM > should be prepared to gracefully ignore things it doesn't expect in > some specified areas of the schema. How broad should this be? > > I'd also like to specify that all parsers should be namespace-aware, > so that third-parties can define their own POM additions via > namespaces. > > FInally, for today, does anyone have any sympathy for focussing on RNG > schema instead of W3C? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
