如何重组Maven多模块项目？
我为这篇文章的篇幅感到抱歉，但是如果没有提供图片，我就很难让它更简洁。 我最近inheritance了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定义了构建项目所需的所有模块，以及在不同子模块中使用的工件版本号的一堆属性：
../module1 ../module2 ../module3 3.0.5.RELEASE 1.6.4 ${snapshots.repo.url} 1.2.3 1.2.3
反过来，每个模块的pom通过pom的工件编号依赖于父pom：
com.cws.cs.lendingsimulationservice parent-pom 1.0.6
为了使事情更加混乱，实际的工件名称可能会或可能不会（取决于模块）与模块路径匹配。 例如，module1可能位于路径c:\dev\MyEarProject\module1但具有工件名称hibernate-module 。 但是，由于它存储在RTC中的方式，目录在签出时称为module1 。
当然，构建所有内容的最简单方法是进入c:\dev\MyEarProject\parent-pom\并运行mvn clean deploy 。 这在SNAPSHOT模式下工作正常，因为SNAPSHOT repo允许多个部署相同的工件版本。 但在发布模式下，这会失败。
这种结构给我带来了两个问题。
- 每次我需要对父项中的属性进行版本更改时，我必须更新父pom版本号，并更新所有子模块父pom的版本，以及所有子模块版本本身（因为父项已更改）。
- 每当我需要部署一个发布周期时，如果其中一个模块自上一个周期以来没有改变，mvn将抛出一个错误，因此无法重新部署到同一个repo（repo不允许覆盖现有的工件）
所以我正在寻找重组这个项目的最佳方法来避免这些问题。 对于父pom，我知道我可以使用相对路径指向父代。 但是，考虑到模块的“扁平”结构，这是一种推荐的方法（即：父pom相对路径是../parent-pom/pom.xml – 对我来说似乎有点奇怪）？ 另外，鉴于父版本的版本控制独立于模块，使用相对路径不仅会打开额外混淆的大门（即：无法知道哪个版本的父pom与哪个版本相关联子模块）。
其次，如何在不遇到我所遇到的部署错误的情况下构建整个耳朵？ 由于工件已存在于repo中，因此我无需重建和重新部署它。 我尝试使用–projects但是涉及的模块数量很难管理。
我真正推荐的第一件事是重新构建项目文件夹…这意味着让projects文件夹代表结构，这意味着不要展平结构。
+-- parent-pom (pom.xml) +--- module1 (pom.xml) +--- module2 (pom.xml) +--- module3 (pom.xml)
因此，您的父级的模块部分将简化为：
module1 module2 module3
此外，模块中的父条目可以简化，如下所示：
com.cws.cs.lendingsimulationservice parent-pom 1.0.6
……这让我想到了下一点：
如果你当前的所有项目都定义了他们的父项，那么这是完全错误的，因为将尝试在存储库中找到父级而不是在上级文件夹中。 换句话说，这会导致你发布许多问题。
如果我们要修复这个问题，它必须看起来像我不能推荐的那样：
com.cws.cs.lendingsimulationservice parent-pom 1.0.6 ../parent-pom/pom.xml
我观察到的另一件事是你不使用SNAPTSHOT ，它将在发布阶段被发布插件取代。 与此相关，它将自动更改适当父母等的所有版本。
在理想情况下，您的模块应如下所示：
com.cws.cs.lendingsimulationservice parent-pom 1.0.6 module-1
因为所有模块将从其父级inheritance版本和groupId 。 有时它更改模块groupId是有用的或需要的，但它是一个例外。
关于我重读的事情是关于父母的单独版本控制。 这根本没有意义，因为它是模块的父级，所以把它放到相同的结构中，当然也就是相同的VCS。
如果你想制作一些配置/插件版本，应该用于其他项目的依赖项，而不是单独的公司pom.xml ，这是一个单独的项目，将单独发布等。
完成结构更改后，您可以直接进入parent-pom目录并执行mvn clean package或mvn release:prepare release:perform从该文件夹mvn release:prepare release:perform ，一切都会更简单。
如果您要发布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/
您的存储库管理器也可能允许覆盖现有版本，但最好只发布新版本。
我更倾向于使用平面模块结构，因为它允许使用父文件夹来存储常用文件，例如checkstyle配置。 我还发现跨模块共享组ID然后将模块目录命名为artifactId是有用的。
你提出了矛盾的要求。 你想重组你的项目，但不能移动东西。 您希望简化部署和发布周期，但不希望使用单个版本。
鉴于一个模块的更改将不可避免地影响所有依赖模块，我将使用一个简单的版本方案，其中所有子模块inheritance其父版本。 maven发布：准备和发布周期变得简单。 使用发行说明来跟踪您的更改并certificate跳过对未更改模块的不必要测试的合理性（对版本的更改不会更改构建过程的构建/二进制输出，因此您可以将其用作主要参数）。
祝你的项目好运。