如何重组Maven多模块项目？

Question

我为这篇文章的篇幅感到抱歉,但是如果不提供图片,我就很难让它更简洁.我最近继承了maven 3.0多模块项目的build-master的工作.问题是项目/模块的结构是一场灾难.从事物当前存储在源代码管理(我们使用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可以位于路径中c:\dev\MyEarProject\module1但具有工件名称hibernate-module.但是,由于它存储在RTC中的方式,目录module1在签出时被调用.

当然,构建一切的最简单方法是进入c:\dev\MyEarProject\parent-pom\并运行mvn clean deploy.这在SNAPSHOT模式下工作正常,因为SNAPSHOT repo允许多个部署相同的工件版本.但在发布模式下,这会失败.

这种结构给我带来了两个问题.

1. 每次我需要对父项中的属性进行版本更改时,我必须更新父pom版本号,并更新所有子模块父pom的版本,以及所有子模块版本本身(因为父项已更改).
2. 每当我需要部署一个发布周期时,如果其中一个模块自上一个周期以来没有改变,则mvn将抛出一个错误,因此无法重新部署到同一个repo(repo不允许覆盖现有工件)

所以我正在寻找重组这个项目的最佳方法来避免这些问题.对于父pom,我知道我可以使用相对路径指向父节点.但是,考虑到模块的"扁平"结构,这是一种推荐的方法(即:父pom相对路径是../parent-pom/pom.xml - 对我来说似乎有点奇怪)？另外,鉴于父版本的版本控制独立于模块,使用相对路径不仅会打开额外混淆的大门(即:无法知道哪个版本的父pom与哪个版本相关联子模块).

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

Answer 1

我真正推荐的第一件事是重新构建项目文件夹...这意味着让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>

......这让我想到了下一点:

如果您当前的所有项目都定义了他们的父项,这是完全错误的,因为将尝试在存储库中找到父级而不是在上级文件夹中.换句话说,这会导致你发布许多问题.

如果我们要修复这个问题,它必须看起来像我不能建议:

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

您完成后的结构变化,你可以简单地进入父-POM目录并做mvn clean package或mvn release:prepare release:perform从该文件夹,一切都将更加简单.