On Dec 11, 2008, at 7:48 PM, "Shane Isbell" <[email protected]>
wrote:
The idea here is not to do away with modelVersion, but rather to add
an
additional parameter, similar to modelGroupId.
Something that I think would be useful is a language/platform element.
Then it's purely additions to the POM. If you could identify the
language/platform and it's version would that be enough for you?
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.
That would be pretty powerful. I would prefer to use Bryon's method
and avoid XSD validation and tooling like the plague. Only downside is
IDE support I suppose. Could probably internally generate the XSD for
the XML editors in the current IDEs.
Shane
On Thu, Dec 11, 2008 at 10:04 AM, Jason van Zyl
<[email protected]>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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
