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.
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).
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.
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.
-- Kenney
> I personally do more as you do.
>
> I have team-wide "super-POMs" I have a primary one that has basic
> url, issue management, etc. type settings. Then I have a "core" POM
> with common dependencyManagment section to encourage use of the same
> versions of Jar's to prevent incompatibilities, as well as common
> reporting configuration. Then I have a "webapp" parent POM that
> specifically states the provided dependencies for webapps to be
> deployed to our target server, as well as webapp specific stuff, such
> as setting <finalName>${project.artifactId}</finalName> to remove the
> version number from wars, and <wtpVersion>1.0</wtpVersion> for the
> Eclipse plugin.
>
> For multi-module project, I have an aggregating POM that defines the
> modules, but each module uses the appropriate "super-POM" as its
> parent, not the aggregating POM.
>
> I've found this to work better for us. But I too have been wondering
> what the reasoning for the pattern of using the aggregating POM also
> as the parent POM is...
>
> -Stephen
>
> On 6/12/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > this is kind of a best-practise-question about your habbits of using
> > the concepts of multi-project-super-pom.
> >
> > First of all, are there distinctive terms commonly agreed upon for
> > each of those concepts?
> >
> > Second, those two ways of using POMs appear to me to be orthogonal to
> > each other, really. Parent POMs are used to define common
> > characterisitics for a group of projects. Multi Project POMs on the
> > other hand aggregate modules belonging to a greater project. I usually
> > have the habbit of defining two diffent poms for multiproject
> > situations. e.g.:
> >
> > /multiproject-pom X
> > -parent-pom Y
> > -module A / pom A (parent pom: Y)
> > -module B / pom B (parent pom: Y)
> >
> > In most examples found though (e.g. in maven's own sources themselfs)
> > typically multi project poms at the same time are used as parent poms
> > for those modules they aggregated.
> >
> > So, what I can't get my head around yet is, is it just a matter of
> > habbit or taste to combine those two usages in just one POM? or am I
> > really missing something important here, if I define two distinctive
> > POMs the way described above.
> >
> > I'm thinking about this for quite a while now and any clarification
> > would be much appreciated.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Stephen Duncan Jr
> www.stephenduncanjr.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
