On 2007-08-02 12:28:04 +0200, Jason Dillon <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
