模块继承 vs 聚合 [英] Module inheritance vs aggregation

问题描述

我们有一个大而深的模块结构，其中包含三个真实"模块.层继承和三到四层模块聚合.<​​/p>

我对真正的继承感到满意:公司范围的超级 pom、产品范围的父级和用于产品定制的客户范围的父级.

但我观察到空的"也是如此.聚合模块被定义为其子模块的父模块.

如果整个概念与 OO 中的相同，那么如果聚合模块(除了它们的子模块之外都是空的)没有向 pom 添加任何特定配置，这对我来说毫无意义.

是否还有其他原因(可能是操作上的)为什么这会很有用?

旁注:在这方面对 pom 的介绍并不明确:术语父级"不清楚:它可能意味着超级 pom(=继承树中的父级)或聚合 pom(=文件系统中的父级...)

解决方案

Maven 社区对这些概念的定义存在很大问题.您说 parent-pom 是 继承 而 module-pom 是 组合 是对的.但不幸的是，这两个概念的分离在 Maven 中没有历史.Maven 文档明确指出最好将它们分开.这将导致这种理想的结构

app-api/应用实现/应用战争/应用父/pom.xml

其中 pom.xml 是模块 pom.

但是几乎你在开源领域看到的每个项目都没有区分它们.

这是有原因的:许多插件也没有区分它们.甚至 Maven 本身也假定另一个设置:如果 未设置，Maven 假定父级位于 ...所以每个项目都必须指向 ../app-parent 作为父项.

最流行的插件有上述结构的巨大问题是 maven-release-plugin！当你不遵循 module-pom 是 parent-pom 的假设时，你会遇到奇怪的问题.

最糟糕的错误是 release-plugin 无法替换您父级中的 version-properties，并且由于 SNAPSHOT-Dependencies 而失败.你的父母可能会包含这样的东西

<app-api.version>1.1-SNAPSHOT</app-api.version><app-impl.version>1.2-SNAPSHOT</app-impl.version></属性><依赖管理><依赖项><依赖><groupId>myorg</groupId><artifactId>app-api</artifactId><version>${app-api.version}</version></依赖><依赖><groupId>myorg</groupId><artifactId>app-impl</artifactId><version>${app-impl.version}</version></依赖></依赖项></dependencyManagement>

通常在发布这些属性时会自动设置为它们的发布版本 1.1 和 1.2.但是 release-plugin(测试到 2.2.2 版本)失败，并显示无法使用快照依赖项发布模块的消息.

如果你只是跳过"当您正确定义 时，某些模块 poms 这可能不是问题.但是您必须尝试并期待 Maven 插件中的一些错误.除了这些错误之外，您将 poms 分开是完全正确的，如果您有时间进行沙盒发布，我会尝试一下.

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...)

解决方案

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.

这篇关于模块继承 vs 聚合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！