Module inheritance vs aggregation

Question

We have a big and deep module structure with three "real" layers of inheritance and three to four layers of module aggregation.

I am fine with the real inheritance: a company wide super-pom, a product-wide parent and a customer-wide parent for customizations of the product.

But I observe that also the "empty" aggregating modules are defined as parents of their submodules.

If the whole concept is the same as in OO, this makes no sense to me if the aggregating modules (they are empty besides their submodules) add no specific configuration to the pom.

Is there any other reason (perhaps operational) why this could be useful?

Sidenote: Introduction to the pom is not clear in this respect: term "parent" is not clear: it can mean super-pom (=parent in inheritance tree) or aggregating pom (=parent in filesystem...)

this doesn't answer your question but if you have separated aggregation from inheritance (which i also tend to do) why are you inheriting from your aggregator poms? in the poms that get aggregated don't specify a section or inherit from your real parent. Basically, _"empty" aggregating modules are defined as parents of their submodules_ is not mandatory. don't do it if it doesn't make sense — Hilikus, Jul 05 '13 at 14:33

score 28 · Accepted Answer · edited Aug 29 '20 at 11:43

There is a great problem in the definition of these concepts in the Maven community. You are right with stating that a parent-pom is inheritance and module-pom is composition. But unfortunately the separation of these two concepts have no history in Maven. The Maven documentation says clearly that it is better to separate them. This would result in this ideal structure

app-api/
app-impl/
app-war/
app-parent/
pom.xml

Where pom.xml is the module pom.

But almost every project you will see in the open source sector does not distinguish between them.

This has a reason: Many plugins do not distiguish between them as well. And even Maven itself assumes another setting: If <relativePath> is not set Maven assumes that the parent is at ... So every project has to point to <relativePath>../app-parent</relativePath> as parent.

The most popular plugin that has huge problems with the mentioned structure is the maven-release-plugin! You will face strange problems when you do not follow the assumption that the module-pom is the parent-pom.

The worst bug is that the release-plugin cannot replace version-properties in your parent and fails because of SNAPSHOT-Dependencies. Your parent perhaps will contain something like this

<properties>
    <app-api.version>1.1-SNAPSHOT</app-api.version>
    <app-impl.version>1.2-SNAPSHOT</app-impl.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>myorg</groupId>
            <artifactId>app-api</artifactId>
            <version>${app-api.version}</version>
        </dependency>

        <dependency>
            <groupId>myorg</groupId>
            <artifactId>app-impl</artifactId>
            <version>${app-impl.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Normally while releasing these properties would automatically be set to their release versions 1.1 and 1.2. But the release-plugin (tested up to version 2.2.2) fails with a message that the module cannot be released with snapshot dependencies.

If you only "skip" some module-poms this might not be a problem when you define <relativePath> correctly. But you have to try and expect some bugs in Maven plugins. Besides these bugs you are totally right to seperate the poms and I would give it a try if you have the time to make a sandboxed release.

Another way of justifying the better way to do this is that this provides "separation of concerns". By separating the notions of inheritance and aggegration, both of them can be more flexible. — David M. Karr, Feb 02 '16 at 22:14
Maven documents state the separation is a good thing a priori. Invoking the holy incantation of "separation of concerns" is meaningless unless the specific concerns are identified. Is it really better? Exactly why in the real world? The costs of separation are real. Besides the functional problems identified above, perhaps the worst part is complexity for us poor humans left to manage the mess. — Charlie Reitzel, Jun 27 '23 at 17:15

score 3 · Answer 2 · answered Jul 05 '13 at 14:39

3

The short answer IIUC is, you don't inherit from your aggregation-only poms. You do when your aggregator is the same as your parent, as in the canonical maven structure. But if you separate aggregator from parent, don't inherit from the aggregator

answered Jul 05 '13 at 14:39

Hilikus

9,954
14
65
118

score 2 · Answer 3 · answered Jul 05 '13 at 13:37

The inheritance of a parent pom is usefull if you have properties that are valid for several projects. From what I understood you already got that part right ;-)

What you call aggregating modules has a valid practical use too. You can group several submodules into a single pom. If you want to build your project you mostly don't want to build every module sperately but join them into one single application. This can be done by such a pom that references all the submodules as such. It can't be done with just the concept of a parent pom as it knows nothing of the other modules.

score 1 · Answer 4 · answered Jun 19 '18 at 02:07

1

Adding an eclipse perspective here : when you create maven module within a maven project using eclipse IDE's wizard, by default, the new module will created as child of top level project and also top level project will be an aggregation of child.

answered Jun 19 '18 at 02:07

Dhaval D

1,087
2
14
25

Module inheritance vs aggregation

4 Answers4

Linked