如何重组Maven多模块项目？

Question

对于这篇文章的篇幅，我深表歉意，但是在不展示图片的情况下，我很难使其简洁。我最近继承了一个Maven 3.0多模块项目的build-
master的工作。问题在于项目/模块的结构是一场灾难。从当前事物存储在Source
Control中的方式（我们使用RTC）到模块的pom结构，我正在努力尝试每次完成完整的构建周期。

随着项目层次结构的发展，所有模块都被“扁平化”存储。即：一切都处于同一水平。我有一个父pom，并且所有模块都取决于父。但是，父级与我所有其他模块的级别相同。

例如：

c:\dev\MyEarProject
 + parent-pom
   - pom.xml
 + module1
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module2
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...
 + module3
   - pom.xml (depends on parent-pom)
   - src
   -   main
   -     ...

父pom定义了构建项目所需的所有模块，以及在整个子模块中使用的工件版本号的一堆属性：

<modules>
  <module>../module1</module>
  <module>../module2</module>
  <module>../module3</module>
</modules>

<properties>
    <org.springframework.version>3.0.5.RELEASE</org.springframework.version>
    <slf4j.version>1.6.4</slf4j.version>
    <repositoryAddress>${snapshots.repo.url}</repositoryAddress>
    <my.hibernate-module.dao.impl>1.2.3</my.hibernate-module.dao.impl>
    <my.hibernate-module.dao.api>1.2.3</my.hibernate-module.dao.api>
</properties>

每个模块的pom依次通过pom的工件编号取决于父pom：

<parent>
    <groupId>com.cws.cs.lendingsimulationservice</groupId>
    <artifactId>parent-pom</artifactId>
    <version>1.0.6</version>
</parent>

为了使事情更加混乱，实际的工件名称可能（也可能不）（取决于模块）与模块路径匹配。例如，module1可能位于path中，c:\dev\MyEarProject\module1但具有工件名称hibernate- module。但是，由于它在RTC中的存储方式，因此在module1签出目录时会调用该目录。

当然，构建所有内容的最简单方法是进入c:\dev\MyEarProject\parent-pom\并运行mvn clean deploy。在SNAPSHOT模式下，这可以很好地工作，因为SNAPSHOT存储库允许相同工件版本的多个部署。但是在发布模式下，此操作将失败。

这种结构给我造成2个问题。

1. 每次我需要对父级中的属性进行版本更改时，都必须更新父级pom版本号，所有子级模块，父级pom的版本以及所有子级模块本身（因为父级更改）。
2. 每当我需要部署发布周期时，如果自上一个周期以来其中一个模块未更改，则mvn会引发错误，因此无法将其重新部署到同一仓库（仓库不允许覆盖现有工件）

因此，我正在寻找重组此项目的最佳方法，以避免出现这些问题。对于父pom，我知道可以使用相对路径指向父pom。但是，鉴于模块的“扁平”结构，这是推荐的方法吗（即：父pom相对路径为../parent-
pom/pom.xml-
对我来说似乎有点奇怪）？另外，鉴于父版本控制与模块无关，因此将使用相对路径不仅会打开额外的困惑之门（即：无法知道父pom的哪个版本与哪个版本相关联）子模块）。

其次，如何在不遇到部署错误的情况下构建整个耳朵？由于工件已经存在于仓库中，所以我不需要重建和重新部署它。我尝试使用–
projects，但是由于涉及的模块数量很大，因此很难管理。

Answer 1

我真正建议的第一件事是重新构造项目文件夹…这意味着让项目文件夹代表结构，这意味着 不要 展平结构。

  +-- parent-pom (pom.xml)
       +--- module1 (pom.xml)
       +--- module2 (pom.xml)
       +--- module3 (pom.xml)

结果，您的父级的模块部分将被简化为：

<modules>
  <module>module1</module>
  <module>module2</module>
  <module>module3</module>
</modules>

此外，可以简化模块中的父条目，如下所示：

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
</parent>

…将我带到下一点：

如果您当前的所有项目都按上述方式定义了其父级，则这是完全错误的，cause将尝试在存储库中而不是上级文件夹中找到父级。换句话说，这会导致您在发布等方面出现很多问题。

如果我们要解决此问题，它必须看起来像这样，我不建议这样做：

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
  <relativePath>../parent-pom/pom.xml</relativePath>
</parent>

我观察到的另一件事是您不使用SNAPTSHOT，在发布阶段，该插件将由发布插件取代。与此相关的是，它将自动更改相应父级中的所有版本。

在理想情况下，您的模块应如下所示：

<parent>
  <groupId>com.cws.cs.lendingsimulationservice</groupId>
  <artifactId>parent-pom</artifactId>
  <version>1.0.6</version>
</parent>

<artifactId>module-1</artifactId>
<!-- No Version or groupId -->

因为所有模块都groupId将从其父级继承该版本。有时更改模块很有用或需要，groupId但这是一个例外。

我重读的是关于父级的单独版本控制。这根本没有意义，因为它是其模块的父级，因此将其放入相同的结构，当然也放入相同的VCS。

如果要制作一些配置/插件版本，则应将依赖性用于其他项目，而不是创建一个单独的公司pom.xml，该公司是一个单独的项目，并将单独发布等。

完成结构更改后，您可以简单地进入parent-pom目录并从该文件夹执行操作mvn clean package或mvn release:prepare release:perform从该文件夹进行操作，一切将变得更加简单。