The idea here is not to do away with modelVersion, but rather to add an additional parameter, similar to modelGroupId.
I found a post by Bryon here talking about the extensibility: http://freedomandbeer.com/posts/extensible-xml-with-xml-namespaces-and-relaxng If it is possible to grab out extensions of the pom and hand off the nodes to appropriate ModelTransformers, that would be useful, allowing chaining of ModelTransformers for processing. Shane On Thu, Dec 11, 2008 at 10:04 AM, Jason van Zyl <jvan...@sonatype.com>wrote: > > On 11-Dec-08, at 6:48 PM, Shane Isbell wrote: > > I'm encountering an issue with Byldan (.NET version of Maven) and since >> this >> is a general problem, I thought I'd raise it here on the list. I need to >> extend the pom model to include information like the key token id of the >> .NET assembly. Using the modelVersion element of the pom isn't appropriate >> to indicate these platform type extensions. >> >> The key here is to provide enough information in the pom to allow the >> build >> tool to choose the implementation of the ModelTransformer it needs. For >> example, if Maven sees Maven:4.0.0, then it chooses PomClassicTransformer >> to >> read the information into the canonical data format. If Maven sees >> dotnet:1.0.0, then Maven could use DotnetModelTransformer, and so on. >> >> Some ideas: >> 1) qualify modelVersion with platform: dotnet:1.0.0, maven:4.0.0 >> 2) new platform tag >> 3) use of namespaces >> 4) Some unique id that maps to transformer >> >> I'm leaning toward (4) as it is more future proof to changes. Thoughts? >> >> > But you still probably want to account for different versions of the model. > I think we also need to look at Bryon Jacob's proposal again about > extensibility with validation. > > Thanks, >> Shane >> > > 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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
