Hi Kenney,
2006/6/13, Kenney Westerhof <[EMAIL PROTECTED]>:
On Mon, 12 Jun 2006, Stephen Duncan wrote:
Hi,
I'd thought I'd throw in a pair of $0.01..
Using the aggregating POM as the parent pom implies that the projects
are structured in a directory structure matching the child->parent
relationship. That means that the child->parent relationship is the
inverse of the parent->module relationship.
A simple sample is the grouping of a set of plugins. Since they're
siblings in the directory structure, the parent pom can easily serve as
the parent pom, defining all things common to plugins.
"...the parent pom can easily serve as the parent pom..." ;-)
Isn't there any more precise wording?
But like you, I've also found that this sometimes gives problems,
since there's no multiple inheritance. In my case it was when working on a
project that consists of two applications, both EARs each containing a WAR
using the same web framework (and thus sharing some settings and
dependencies). The modules were grouped by application, and using the
parent-as-aggregator there's no way to let both WAR projects have the same
settings if they're not siblings in the directory structure. There's also
some common POM configuration for the two applications (for instance the
groupId's).
Another advantage, more of convenience, of differ between parent and
aggregating pom: you can have the parent pom at the same level as it's
inherited poms. Thus in Eclipse I can edit at least the parent pom
easily, since I can import it as a Eclipse project. This is not true
for the aggregating pom, though. But since typically the parent pom is
more often edited than the aggregating pom, this is fine by me.
Basically, there are too many relations to fit into a tree (it becomes a
graph), and you just have to pick the one that makes the most sense.
In my experience, it's convenient to have the parent pom
as an aggregator so your project tree is actually a tree.
OK, understood. (But with the lack of not beeing able to edit the
parent pom easily inside Eclipse.)
On a side note, there are some plugins, like the site plugin, that
currently kind of expect the parent->module relationship to be
bidirectional (meaning modules must specify the aggregator as their parent).
The behaviour of this plugin depends on whether it's run in reactor-mode
or not, and when the modules define different parents, you get unexpected
results. But this is being addressed.
See, it's the implicit assumptions, that make me scratch my head.
-- Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
