使用Maven进行软件版本控制和多模块项目的最佳实践是什么？我的意思是，当我用Maven创建一个多模块项目时，什么是版本控制的最佳方法？对所有模块使用一个版本（在顶层项目中定义）？对每个模块使用一个版本（在每个模块的POM中定义）？是否还有其他我遗漏的方法？每种方法的优缺点是什么？通常，不同的模块是否一起发布（可能共享相同的版本号）？谢谢
ki0zmccv1#
老实说，这取决于你想做什么。创建多模块项目有多个原因，其中之一是你只需要部署已经更改的模块，而不是所有模块。你可以这样想：如果您有一个非多模块项目，并且只需要更改服务层中的一行代码，则必须重新构建整个项目并再次部署所有代码...即使只有服务层会发生更改。使用多模块项目，您可以重新生成项目，并只部署更改的内容...您的服务。这降低了风险，并确保只有您的服务模块发生了更改。使用多模块项目还有很多好处，我没有在这里列出，但是不保持模块的版本号同步肯定有巨大的好处。当你构建你的项目时，考虑将它部署到一个存储库中，这个存储库将所有兼容的jar保存在一起以供构建（每个构建都会创建一个新的文件夹，其中包含最父级的pom版本号）。这样，你就不需要保存关于哪些jar是兼容的文档......它们只需要与一个构建号一起部署。
i1icjdpr2#
我自己也在寻找解决这个问题的方法，而versions-maven-plugin正是我所需要的。我不喜欢与SCM系统通信的版本插件。版本插件做的正是我们所需要的：它在项目的所有pom中设置一个新的版本号：
mvn versions:set -DnewVersion=2.0.0
版本插件取决于maven多模块项目的组织方式：因此，它通常不会更新复杂的多模块项目中的所有POM文件。
sed -i 's/1.0.0-SNAPSHOT/1.0.0-RC1/g' `find . -name 'pom.xml'`
q8l4jmvw3#
通常您创建一个多模块项目，因为您认为各个模块是一个整体的组成部分。可能是客户端、控制器和服务，也可能是包含服务的UI。在任何情况下，让各个模块的版本号以锁步方式移动是有意义的。关于你的问题不同的模块是否一起发布（可能共享相同的版本号）我想是的。这是多模块项目的原因之一。否则你可以把模块作为独立的项目。当然，这是那种充斥着边缘案例和例外的东西;- ）
fafcakar4#
我在使用a project I`m working on时也遇到了同样的问题。我还决定使用单独的版本，甚至对父pom的依赖也只需要在某些托管依赖发生变化时更新。（正如@vinnybad所描述的那样）
通过使用“org.honton.chas.exists-maven-plugin”，只有那些实际上已经改变的模块才会被部署到库中，这真的很棒，因为相应的docker-images也只会在某个服务上发生改变时才被发布。这避免了用不同但未改变的版本“污染”图像库。
“分离版本”方法的一个主要缺点是关于版本控制的问题：
为了解决这个问题，我把所有的模块版本都放到了父pom的依赖性管理部分，即使没有其他模块依赖它们。一个“集成测试”模块可以通过依赖所有的模块来解决这个问题--当然也可以一起测试它们。这样的话，我将“被迫”更新父pom的每一个变化，因为它是指已发布的模块版本。这样的话，父pom将有“主导”版本，在依赖管理块状态，所有模块的版本是相互兼容的（这将通过集成测试来确保）。
4条答案
按热度按时间ki0zmccv1#
老实说，这取决于你想做什么。创建多模块项目有多个原因，其中之一是你只需要部署已经更改的模块，而不是所有模块。
你可以这样想：如果您有一个非多模块项目，并且只需要更改服务层中的一行代码，则必须重新构建整个项目并再次部署所有代码...即使只有服务层会发生更改。
使用多模块项目，您可以重新生成项目，并只部署更改的内容...您的服务。这降低了风险，并确保只有您的服务模块发生了更改。
使用多模块项目还有很多好处，我没有在这里列出，但是不保持模块的版本号同步肯定有巨大的好处。
当你构建你的项目时，考虑将它部署到一个存储库中，这个存储库将所有兼容的jar保存在一起以供构建（每个构建都会创建一个新的文件夹，其中包含最父级的pom版本号）。这样，你就不需要保存关于哪些jar是兼容的文档......它们只需要与一个构建号一起部署。
i1icjdpr2#
我自己也在寻找解决这个问题的方法，而versions-maven-plugin正是我所需要的。我不喜欢与SCM系统通信的版本插件。版本插件做的正是我们所需要的：它在项目的所有pom中设置一个新的版本号：
编辑：
版本插件取决于maven多模块项目的组织方式：因此，它通常不会更新复杂的多模块项目中的所有POM文件。
q8l4jmvw3#
通常您创建一个多模块项目，因为您认为各个模块是一个整体的组成部分。可能是客户端、控制器和服务，也可能是包含服务的UI。
在任何情况下，让各个模块的版本号以锁步方式移动是有意义的。
关于你的问题
不同的模块是否一起发布（可能共享相同的版本号）
我想是的。这是多模块项目的原因之一。否则你可以把模块作为独立的项目。
当然，这是那种充斥着边缘案例和例外的东西;- ）
fafcakar4#
我在使用a project I`m working on时也遇到了同样的问题。我还决定使用单独的版本，甚至对父pom的依赖也只需要在某些托管依赖发生变化时更新。（正如@vinnybad所描述的那样）
两个加法
存在-maven-插件
通过使用“org.honton.chas.exists-maven-plugin”，只有那些实际上已经改变的模块才会被部署到库中，这真的很棒，因为相应的docker-images也只会在某个服务上发生改变时才被发布。这避免了用不同但未改变的版本“污染”图像库。
版本控制
“分离版本”方法的一个主要缺点是关于版本控制的问题：
为了解决这个问题，我把所有的模块版本都放到了父pom的依赖性管理部分，即使没有其他模块依赖它们。一个“集成测试”模块可以通过依赖所有的模块来解决这个问题--当然也可以一起测试它们。
这样的话，我将“被迫”更新父pom的每一个变化，因为它是指已发布的模块版本。这样的话，父pom将有“主导”版本，在依赖管理块状态，所有模块的版本是相互兼容的（这将通过集成测试来确保）。