如何重组Maven多模块项目？

Question

我赞同这篇文章的篇幅，但我很难在不呈现图片的情况下使它更简洁。我最近继承了maven 3.0多模块项目的构建主程序的工作。问题是项目/模块的结构是一场灾难。从目前存储在源代码管理(我们使用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。这在快照模式下工作很好，因为快照回购允许同一个工件版本的多个部署。但在发布模式下，这是失败的。

这个结构给我造成了两个问题。

每次我需要对父程序中的属性进行版本更改时，我必须更新父-pom版本号、所有子模块的父changed).

• Whenever版本以及所有子模块的版本本身(因为父需要部署发布周期，mvn将抛出一个错误，如果其中一个模块自上一个周期以来没有更改，因此无法重新部署到相同的(回购不允许覆盖现有构件)

。

因此，我正在寻找最好的方法来重组这个项目，以避免这些问题。对于父pom，我知道我可以使用一个相对路径来指向父进程。但是，考虑到模块的“平面”结构，这是否是一种推荐的方法(即:父pom相对路径应该是./ parent -pom/pu.xml--对我来说似乎有点奇怪)？此外，考虑到父模块的版本控制独立于模块，那么使用相对路径不仅会导致额外的混乱(即:无法知道父pom的哪个版本与子模块的哪个版本相关联)。

其次，如何在不遇到部署错误的情况下构建整个ear？因为工件已经存在于回购程序中，我不需要重新构建和重新部署它。我试过使用--项目，但是随着模块数量的增加，管理变得非常困难。

Answer 1

我真正推荐的第一件事是重组项目文件夹，...which意味着让projects文件夹表示结构，这意味着结构不会变平。

  +-- 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>

...which把我带到了下一个问题：

如果您当前的所有项目都将其父项目定义为以上所示，则会尝试在存储库中而不是在较高级别的文件夹中找到父项目。换句话说，这导致了你在发布等方面的很多问题。

如果我们要解决这个问题，它必须是这样的，我不能建议：

<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，这是一个单独的项目，并将单独发布等等。

在完成结构更改之后，您只需进入父目录并从该文件夹执行mvn clean package或mvn release:prepare release:perform操作，一切就会更简单。

Answer 2

如果要发布POM，则必须发布任何更新，但不需要手动修改POM版本--您可以使用版本插件或发布插件自动更新版本。我倾向于更喜欢发布插件，因为它将致力于SCM为您。

mvn versions:set 

http://mojo.codehaus.org/versions-maven-plugin/

mvn release:prepare release:perform

http://maven.apache.org/plugins/maven-release-plugin/

您的存储库管理器也可能允许覆盖现有版本，但最好只是发布一个新版本。

我倾向于使用平面模块结构，因为它允许使用父文件夹来存储公共文件，例如校验样式的配置。我还发现在模块之间共享组id很有用，然后将模块目录命名为与artifactId相同的目录。

Answer 3

你提出了自相矛盾的要求。你想重组你的项目，但不能移动东西。您希望简化部署和发布周期，但不希望使用单个版本。

考虑到一个模块中的更改将不可避免地影响所有依赖模块，我将使用一个简单的版本化方案，其中所有子模块都继承其父模块的版本。maven发行版:准备和发布周期变得简单。使用发布说明跟踪您的更改，并证明跳过对未更改模块的不必要测试是合理的(对版本的更改不会更改构建过程的构建/二进制输出，这样您就可以使用它作为您的主要参数)。

祝你的项目好运。