You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Shane Isbell <sh...@gmail.com> on 2008/12/11 18:48:43 UTC
Extending the Pom
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?
Thanks,
Shane
Re: Extending the Pom
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Shane,
>
>> 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?
>
>
> For this element, I think it would be better to have something more general.
> For example, I may want slightly different pom extensions for both Byldan
> and NMaven, both of which have the same platform.
>
> I do think, however, that also having a platform element within the pom is a
> good idea, as this would allow the artifact provider to specify target
> platform requirements for the artifact. This could then be matched against
> the Maven toolchain config, which would provide the build capabilities. I
> talked with Oleg yesterday about this and he said that we could define
> custom SAT rules for Mercury, allowing us to pull in different dependency
> chains, based on the toolchain/platform.
>
> Shane
>
Do you know the concept that we Java guyz use for picking the correct platform
specific dependency (e.g. when native code is involved).
If you are interested, have a look here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=199302
Some link is broken but the attached POM is showing the idea.
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoPLeAACgkQmPuec2Dcv/+rvgCeInXXB8PmS+fCPkSHT4rzNS3J
hiYAoInA+/01uw81dttP4snGQN/qxAwq
=Pyb1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the Pom
Posted by Shane Isbell <sh...@gmail.com>.
On Thu, Dec 11, 2008 at 10:58 PM, Jason van Zyl <jv...@sonatype.com>wrote:
>
> 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?
For this element, I think it would be better to have something more general.
For example, I may want slightly different pom extensions for both Byldan
and NMaven, both of which have the same platform.
I do think, however, that also having a platform element within the pom is a
good idea, as this would allow the artifact provider to specify target
platform requirements for the artifact. This could then be matched against
the Maven toolchain config, which would provide the build capabilities. I
talked with Oleg yesterday about this and he said that we could define
custom SAT rules for Mercury, allowing us to pull in different dependency
chains, based on the toolchain/platform.
Shane
Re: Extending the Pom
Posted by Jason van Zyl <jv...@sonatype.com>.
On Dec 11, 2008, at 7:48 PM, "Shane Isbell" <sh...@gmail.com>
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
> <jv...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Extending the Pom
Posted by Shane Isbell <sh...@gmail.com>.
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 <jv...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Extending the Pom
Posted by Jason van Zyl <jv...@sonatype.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org