On 2007-07-28 23:41:18 +0200, Jason Dillon <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
