You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jochen Kuhnle <jo...@kuhnle.net> on 2007/08/02 11:57:09 UTC
Re: Importing poms, as well as extending them
On 2007-07-28 23:41:18 +0200, Jason Dillon <ja...@planet57.com> said:
> On Jul 28, 2007, at 8:52 AM, Jason van Zyl wrote:
>> On 28 Jul 07, at 8:56 AM 28 Jul 07, Jason Dillon wrote:
>>> Folks, I think this may have come up before, though I've not gone
>>> digging in the jira or mailing list trenches for it...
>>>
>>> I would be *really, really useful* if a pom could include other poms
>>> into its effective pom *in addition to* the parent pom. The parent
>>> pom and tree structure is very useful for defining projects and scoped
>>> configuration muck for a single project, but when wanting to share
>>> more pom elements with many projects, the inheritance model breaks
>>> down significantly and ends up causing projects to duplicate elements
>>> to control common build scenarios, which then causes more
>>> maintenance... and in the end ultimately ends up in a rather big mess
>>> :-(
>>>
>>
>> Composition versus inheritance. The same problem has arisen with the POM.
>>
>> For something like a release profile, or release tool chain and import
>> or mixin approach would be far more convenient.
>
> Yes, this is really what I'm thinking of. A way to mixin a shared
> profile, or to configure a set of dependency and plugin versions which
> have been _blessed_, etc.
>
>
>> The problem is how and where to get the information to mixin. I think
>> it should come from the repository, so something like the release
>> profile becomes a mixin taken from a reliable source like the
>> repository. Otherwise being able to mixin anything potentially leads
>> to build portability problems. In order to do this we also have a not
>> to trivial task of figuring out what takes precedence, merging versus
>> aggregation ... and we really don't have solid rules for much of this
>> behavior at the moment.
>
> I'm definitely thinking that the bits to mixin come from the
> repository, and I'm even thinking they are just regular old poms...
> configured like:
>
> ----8<----
> <project>
> <modelVersion>...
> <parent>
> ...
> </parent>
>
> <imports>
> <import>
> <groupId>foo.bar</groupId>
> <artifactId>some-shared-pom-muck</artifactId>
> <version>1.0</version>
> </import>
> </imports>
> </project>
> ---->8----
Couldn't it just be multiple parents, like
<parents>
<parent>
...
</parent>
<parent>
...
</parent>
</parents>
This would only be a small extension to the POM format and POM assembly
code, and would not introduce new concepts.
>
> I know that the precedence thing may be problematic... so I suggest a
> simple solution of exposing an additional element in the <import>
> bits, which are optional to control how that pom is merged in. Of
> course we come up with some reasonable default, say, always overlay
> that stuff last after parent is merged in. But maybe the user might
> want the imported pom to take precedence, or for the import to take
> precedence over the parent, but not other profiles, etc.
How about a general mechanism working for all kinds of "combination"
(parents, profiles, *management sections). Right now, you can use the
"combine.*" attributes, which could be extended to allow more
fine-grained combination control (e.g. removal of parts of a list).
Precedence then can stay as it is now, and the user can explicitly
specify what parts of the pom should be combined in which way.
Regards,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jochen Kuhnle <jo...@kuhnle.net>.
On 2007-08-02 12:28:04 +0200, Jason Dillon <ja...@planet57.com> said:
> On Aug 2, 2007, at 2:57 AM, Jochen Kuhnle wrote:
>>
>> Couldn't it just be multiple parents, like
>>
>> <parents>
>> <parent>
>> ...
>> </parent>
>> <parent>
>> ...
>> </parent>
>> </parents>
>> This would only be a small extension to the POM format and POM
>> assembly code, and would not introduce new concepts.
>
> Not really, since you need to know which is your "real" parent when
> rendering site details, and some common bits of pom.xml might not
> really be suitable for calling your parent either.
The "real" parent would be the last one mentioned in the pom. Parents
could be used in order of their appearance. Currently, if a pom M has a
parent P1, the effective POM is built by combining P1 and M, with M
taking precedence over P1. If M had multiple parents (P1, P2, P3) the
effective pom should be created by combining P1, P2, P3 and M (in this
order). This way, any value of the effective POM comes from M, P3, P2
or P1 (in this order), whichever first specifies it. I think that
assinging an order to the parents is ok, because with imports, you also
have to.
>
>
>>> I know that the precedence thing may be problematic... so I suggest a
>>> simple solution of exposing an additional element in the <import>
>>> bits, which are optional to control how that pom is merged in. Of
>>> course we come up with some reasonable default, say, always overlay
>>> that stuff last after parent is merged in. But maybe the user might
>>> want the imported pom to take precedence, or for the import to take
>>> precedence over the parent, but not other profiles, etc.
>>
>> How about a general mechanism working for all kinds of "combination"
>> (parents, profiles, *management sections). Right now, you can use the
>> "combine.*" attributes, which could be extended to allow more
>> fine-grained combination control (e.g. removal of parts of a list).
>> Precedence then can stay as it is now, and the user can explicitly
>> specify what parts of the pom should be combined in which way.
>
> Um, you kinda lost me with the "right now" in with "combine.*"...
My mistake, I thought Maven used Xpp3Dom.mergeIntoXpp3Dom from
plexus-utils not only for plugin configurations, but for the pom
itself, too. I found ModelInheritanceAssembler now... With
Xpp3Dom.mergeIntoXpp3Dom, you can use attributes to control the
combination of two elements. E.g. combine.self="override" combines by
using the element with higher precedence, combine.self="merge" combines
by merging both elements' attributes and children.
With this at pom level, it would be possible to specify if e.g. a list
of repositories inherited from the parents should be appended to or
completely overwritten. In addition, it might be useful to have the
ability to remove a single element from a list of inherited elements,
e.g. removing a repository, a plugin execution or a dependency
inherited from a parent.
Regards,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Importing poms, as well as extending them
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 2, 2007, at 2:57 AM, Jochen Kuhnle wrote:
>> ----8<----
>> <project>
>> <modelVersion>...
>> <parent>
>> ...
>> </parent>
>> <imports>
>> <import>
>> <groupId>foo.bar</groupId>
>> <artifactId>some-shared-pom-muck</artifactId>
>> <version>1.0</version>
>> </import>
>> </imports>
>> </project>
>> ---->8----
>
> Couldn't it just be multiple parents, like
>
> <parents>
> <parent>
> ...
> </parent>
> <parent>
> ...
> </parent>
> </parents>
> This would only be a small extension to the POM format and POM
> assembly code, and would not introduce new concepts.
Not really, since you need to know which is your "real" parent when
rendering site details, and some common bits of pom.xml might not
really be suitable for calling your parent either.
>> I know that the precedence thing may be problematic... so I
>> suggest a simple solution of exposing an additional element in
>> the <import> bits, which are optional to control how that pom is
>> merged in. Of course we come up with some reasonable default,
>> say, always overlay that stuff last after parent is merged in.
>> But maybe the user might want the imported pom to take
>> precedence, or for the import to take precedence over the parent,
>> but not other profiles, etc.
>
> How about a general mechanism working for all kinds of
> "combination" (parents, profiles, *management sections). Right now,
> you can use the "combine.*" attributes, which could be extended to
> allow more fine-grained combination control (e.g. removal of parts
> of a list). Precedence then can stay as it is now, and the user can
> explicitly specify what parts of the pom should be combined in
> which way.
Um, you kinda lost me with the "right now" in with "combine.*"...
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org