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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
