Maven模块继承与聚合 [英] maven module inheritance vs aggregation
问题描述
我们拥有一个庞大而深入的模块结构，具有三层真实的"继承层和三层至四层的模块聚合层.
We have a big and deep module structure with three "real" layers of inheritance and three to four layers of module aggregation.
我对真正的继承感到满意:公司范围内的超级pom，产品范围内的父级和客户范围内的产品定制父级.
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.
如果整个概念与OO中的相同，那么如果聚合模块(除了子模块，它们是空的)没有为pom添加任何特定配置，这对我来说就没有意义.
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.
还有其他原因(也许是可行的)为什么这可能有用吗?
旁注:pom的介绍在这方面尚不清楚:术语父"尚不明确:它可能表示超级pom(=继承树中的父)或聚合pom(=文件系统中的父...)
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...)
推荐答案
在Maven社区中，这些概念的定义存在很大的问题.您说对了， parent-pom 是继承和 module-pom 是 composition 是正确的.但是不幸的是，这两个概念的分离尚无历史. Maven文档清楚地表明，最好将它们分开.这将导致这种理想的结构
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
其中pom.xml是模块pom.
Where pom.xml is the module pom.
但是您在开源领域中看到的几乎每个项目都不会区分它们.
But almost every project you will see in the open source sector does not distinguish between them.
这是有原因的:许多插件之间也没有区别.甚至maven本身也假定了另一个设置:如果未设置<relativePath>，则Maven假定父对象位于..处.因此，每个项目都必须指向<relativePath>../app-parent</relativePath>作为父项.
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.
在提到的结构上存在巨大问题的最受欢迎的插件是maven-release-plugin！当您不遵循模块-pom是父-pom的假设时，将会遇到奇怪的问题.
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.
最严重的错误是，发行版插件无法替换父级中的版本属性，并且由于SNAPSHOT依赖关系而失败.您的父母也许会包含这样的内容
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>
通常，在发布这些属性时，这些属性将自动设置为其发布版本1.1和1.2.但是，发布插件(经过2.2.2版测试)失败，并显示一条消息，指出该模块无法通过快照依赖项进行发布.
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.
如果仅跳过"某些模块内存，则正确定义<relativePath>时可能不会出现问题.但是您必须尝试预期Maven插件中的一些错误.除了这些错误之外，您完全可以将pom分开，如果您有时间制作沙盒版本，我会尝试一下.
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.
这篇关于Maven模块继承与聚合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
