Question

我们有一个庞大而深入的模块结构，具有三个“真实”继承层和三到四层模块聚合。</ p>

我对真正的继承很好：公司范围的超级pom，产品范围的父母和客户范围的父母，用于产品的自定义。

但我观察到“空”聚合模块也被定义为其子模块的父级。

如果整个概念与OO中的相同，那么如果聚合模块（除了子模块之外它们都是空的），这对我来说没有任何意义。

还有其他原因（可能是可操作的）为什么这会有用？

旁注：pom的介绍在这方面尚不清楚：术语“父”不清楚：它可能意味着超级pom（=继承树中的父）或聚合pom（=文件系统中的父...）< / p>

Answer 1

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

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

pom.xml是模块pom。

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

这有一个原因：许多插件也不会在它们之间进行区分。甚至maven本身也采用了另一种设置：如果未设置<relativePath>，Maven会认为父项位于..。因此，每个项目都必须指向<relativePath>../app-parent</relativePath>作为父级。

上面提到的结构存在巨大问题的最受欢迎的插件是maven-release-plugin！当你不遵循模块-pom是父pom的假设时，你将面临奇怪的问题。

最糟糕的错误是release-plugin无法替换父级中的version-properties，因为SNAPSHOT-Dependencies而失败。你的父母也许会包含这样的东西

<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。但是release-plugin（测试版本为2.2.2）失败，并显示无法使用快照依赖项发布模块的消息。

如果您只是“跳过”某些模块poms，那么在正确定义<relativePath>时这可能不是问题。但你必须尝试并期待maven插件中的一些错误。除了这些错误之外，你完全正确分开poms，如果你有时间进行沙盒释放，我会尝试一下。

Answer 2

如果您拥有对多个项目有效的属性，则父pom的继承很有用。从我的理解，你已经得到了那个部分; - ）

您所谓的聚合模块也具有有效的实际用途。您可以将多个子模块组合成一个pom。如果您想构建项目，您通常不希望特意构建每个模块，而是将它们连接到一个应用程序中。这可以通过引用所有子模块的pom来完成。它不能只用父pom的概念来完成，因为它对其他模块一无所知。

Answer 3

简短回答IIUC是，你不会继承你的聚合poms。当聚合器与父级聚合器相同时，就像在规范maven结构中一样。但是如果将聚合器与父聚合器分开，则不要从聚合器继承

Answer 4

在此处添加eclipse透视图：使用eclipse IDE的向导在maven项目中创建maven模块时，默认情况下，新模块将作为顶级项目的子项创建，顶级项目也将成为子项的聚合。

maven模块继承与聚合

4 个答案: