具有各种不同依赖项的 Maven 多模块项目设置

Question

让我先说一下：我是 Maven 的新手。也就是说，我四处搜索，但没有找到以下问题的答案。我找到了类似问题的答案，但不是这种情况。或者，也许我只是误解了答案，而这可以通过多模块设置来解决。

我会有以下依赖层次结构：

database
|  |
|  +---core
|      |  |
|      |  +---business 
|      |        |
|      |        +------App1
|      |        |
|      |        +------App2
|      |
|      +---------------App3
|
+----------------------App4

我想让它工作，这样更改只会导致任何“上游”模块/应用程序的新版本。这确实是多模块 maven 设置的简单案例还是我需要做其他事情？

Answer 1

如果您希望发布一个组件为每个项目生成一个新版本，只需使用maven-release-plugin：http://maven.apache.org/maven-release/maven-release-plugin/。

文档

根据文档，这将：

• 检查源中没有未提交的更改
• 检查是否没有 SNAPSHOT 依赖项
• 将 POM 中的版本从 x-SNAPSHOT 更改为新版本（系统将提示您选择要使用的版本）
• 转换 POM 中的 SCM 信息以包含标签的最终目的地
• 针对修改后的 POM 运行项目测试，以确认一切正常
• 提交修改后的 POM
• 用版本名称标记 SCM 中的代码（将提示输入）
• 将 POM 中的版本添加到新值 y-SNAPSHOT（也会提示输入这些值）
• 提交修改后的 POM

由于 maven 多模块结构，它们被链接在一起，每个项目都会被撞到一个新版本。

简而言之，这将：

• 移动版本 1.0-SNAPSHOT --> 1.1-SNAPSHOT
• 标签 1.0
• 生成 1.0.jar（欧战或其他）

插件使用

假设 SCM 已正确定义，并且配置了存储库和分发管理，只需添加这些行

<project>
  [...]
  <build>
    [...]
    <plugins>
      [...]
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.4.2</version>
        <!-- optional, basic format is ${project.artifactId}-${project.version}.${project.type}-->
        <configuration>
          <tagNameFormat>v@{project.version}</tagNameFormat>
        </configuration>
      </plugin>
      [...]
    </plugins>
    [...]
  </build>
  [...]
</project>

然后调用

mvn release:prepare
mvn release:perform

继承与依赖

你可以考虑两种不同的 Maven 方法：

• 继承，即父模块和多/子模块
• 聚合，换句话说：使用依赖项

在多 Maven 项目中，您的所有模块（包括父模块）共享相同的生命周期。释放一个意味着释放所有，因此，只释放一个是没有意义的。

在您的情况下，您无法在不影响应用 4 的情况下将应用 1 修改为 3。 如果 App 4 依赖于 App 1，显然 App 1 不能依赖于 App 4（不允许循环引用）。

所以，你想把 App4 和 App1 隔离为 3 个生命周期，你不应该使用多模块，而只是共享一个父项目，或者像公司 > 主项目 > 子项目（不是子模块）这样的 pom 层次结构。 之后，只需声明 App 4 和 App 1 之间的依赖关系。(... into app4 pom.xml)

只是另一个想法：您的项目和子模块的名称听起来很奇怪。 “经典”层次结构通常是（考虑大型项目的多业务对象域）：

Main Project (sometimes EAR) --> POM 
|-- Business Object / DAO --> POM
|   |-- Domain 1 --> JAR
|   `-- Domain 2 --> JAR
|-- Core (depends on BO)  --> JAR
`-- IHM / Web App (depends on core)  --> WAR

因此，数据库很少位于层次结构的顶部。