Question

简而言之，我要做的是同时构建一堆库和应用程序，所有Maven项目。根据我的理解，只需在mvn package的一个命令行中完成此操作就可以创建一个多模块项目，该项目将列出我想要构建的每个模块，将它们放入Maven反应器并构建。

在Maven书中的示例后，通常多模块pom位于各个模块上方的目录中。但是，通常情况下，父pom位于模块上方的目录中，这引发了问题，通常情况下多模块构建也应该是父项吗？我想不是;但我想知道为什么我遇到这个有趣的设计怪癖。

所以，我想知道正确的方法来设置它。我看到以下约定/要求：

多模块pom必须知道其他模块在光盘上的位置。由于它实际上是从源代码进行构建，因此它不能简单地依赖已安装的版本（因为它正在安装它们！）
父级实际上并不一定是物理目录，尽管这样做更可取。我认为这是最好打破的惯例。
实际上，各个库/应用程序甚至不需要知道它们是作为多模块构建的一部分构建的。

这通常是如何在多模块构建中设置的？是否有更简单的方法可以同时管理多个Maven项目？

Answer 1

我将所有单个模块放在根模块中。 Some software在多层次的层次结构中遇到问题。

要使子模块在同一级别上引用它的父级：

<parent>
    <groupId>com.domain</groupId>
    <artifactId>xyz</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <relativePath>../xyz/pom.xml</relativePath>
</parent>

我建议您不要在单个模块需要继承的多模块（例如属性）中放置任何内容。如果这样做，您将无法独立构建其他模块。

Answer 2

我甚至会说这是“惯例”的模糊部分。文档和常识都表明项目聚合（也称为多模块构建）和继承是为处理不同用例而提供的两种不同机制。

与此同时，似乎有一个事实上的约定（是的，我知道）将项目聚合和继承父角色组合成一个pom。实际上，父声明的元素和项目aggegration机制的模块元素似乎都引导了对这种组合的使用。

就个人而言，我发现定期将父母pom分开是非常有用的。而且我发现在我的源代码管理中完全分离的位置找到父pom很有用，因此我的文件夹结构也是如此。但是，在源控件/文件夹结构中找到属于同一多模块构建结构的构建很少有用。也许这甚至可以很好地衡量某些东西是否应该包含在同一个聚合构建中;如果它似乎值得在源文件夹结构中进行搭配，那么它可能是一个强大的聚合候选者。

我唯一确信的是，这些东西值得整理一下。而且，在不创建单片构建结构方面，错误可能更好。。。处理一大堆聚合的父子构建模块是非常困难的，这些模块并不是必需的。另一方面，聚合各个构建以一起运行是在更高级别提供的功能，例如CI构建服务器。所以，我想我可能会建议在更多独立性方面出错。

从父pom继承时管理Maven多模块构建

2 个答案: