关于Maven自动化项目版本控制，我有一个难以解决的案例，我希望我能根据您的经验和建议找到合适的解决方案。
问题是这样的： 我们有一个巨大的mavenized java产品，包含~200个非常相互依赖的不同项目。 我们同意每个项目都应该独立开发，这样每个项目都应该拥有自己的生命周期。 它在开发阶段都运行良好，没有问题。当我们为这些项目准备发布时，问题就出现了：因为手动更改的项目非常多，所以我们决定找到一个自动解决方案来解决发布过程。
先决条件是这些： 我们都同意SVN的发布政策应该是这样的： - 所有开发都应该在SVN trunk上执行，应该在分支上创建和维护版本。每个执行的版本都应自动创建一个标记。
MAVEN的政策是这样的： - 在发布项目之前，我们首先将主干复制到分支，以便控制对分支代码的项目维护。我们选择的版本控制系统是： Major.Minor.BuildNumber-SNAPSHOT（例如1.0.0-SNAPSHOT）。分支代码时，我们希望通过递增 MinorVersion来改变项目版本号（例如trunk-1.0.0-SNAPSHOT 将变为 1.1.0-SNAPSHOT，以及1.0.0-SNAPSHOT将在新创建的分支上复制和发布） - 当我们确定项目已经足够成熟以便发布时，我们通过使用 maven-release-plugin 发布它（ mvn发布：清除发布：prepare release：perform ）以便我们的项目版本将从 Major.Minor.BuildVersion-SNAPSHOT（例如1.0.0-SNAPSHOT）转换为 Major.Minor.BuildVersion（例如1.0.0），然后将为下一个开发迭代做好准备，如： Major.Minor.BuildVersion + 1-SNAPSHOT（例如1.0.1-SNAPSHOT）
我们面临的问题与项目版本控制有关。 因此，在主干的开发阶段，所有项目都使用其依赖项的最新SNAPSHOT版本（ mvn版本：use-latest-versions -DallowSnapshots = true -DupdateDependencies = true ），但是我们认为是时候开始发布过程并准备分支代码了，问题就出现了： 我们开始分支
parent-pom
（ mvn -B release：clean release：branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel $ {}的groupId：$ {}专案编号= 1.0.0-SNAPSHOT -Dproject.dev。$ {groupId}：$ {projectId} = 1.1.0-SNAPSHOT ）
非依赖项目
（ mvn -B release：clean release：branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel $ {}的groupId：$ {}专案编号= 1.0.0-SNAPSHOT -Dproject.dev。$ {groupId}：$ {projectId} = 1.1.0-SNAPSHOT版本：update-parent -DallowSnapshots =真）
依赖项目：
（ mvn -B release：clean release：branch -DbranchName = $ {project.artifactId} _ $ {project.version} -Dusername = $ {username} -Dpassword = $ {passwd} -Dproject.rel $ {}的groupId：$ {}专案编号= 1.0.0-SNAPSHOT -Dproject.dev。$ {groupId}：$ {projectId} = 1.1.0-SNAPSHOT版本：update-parent -DallowSnapshots = true版本：use-latest-versions -DallowSnapshots = true -DupdateDependencies =真）
这里的第一个问题是，在分支项目时，还没有办法增加MinorVersion，maven-release-plugin 2.2.2在分支时不会增加主干上的pom MinorVersion，所以＆＃ 39;为什么我们需要使用 -Dproject.rel。$ {groupId}：$ {projectId} = 1.0.0-SNAPSHOT -Dproject.dev。$ {groupId}：$ {projectId} = 1.1.0-SNAPSHOT 参数并为每个项目手动更改它们，每次我们预备新版本时都会更改200次。
我想知道它是不是以某种方式以自动方式制作所有描述的过程并且不需要一直手动执行所有这些更改的方法。 我们甚至考虑到模块化这个产品，以便在100中完成这200个项目，但这是不可接受的，因为我们的想法是进行一个细粒度的项目版本控制并拥有它的所有项目＃s; s自己的生命周期，所以聚合器（我的意思是经典的）在这里没有讨论。
我们使用SVN作为VCS，Maven作为构建工具（可能你已经弄明白了:)）和Bamboo作为CI服务器（实际上，而不是＆＃34; Maven Dependency Processor＆＃34;功能，Bamboo对版本控制问题没有多大帮助。）
你们有任何想法为这个问题找到一个合适的解决方案，也许是另一个有帮助的插件（版本-maven-plugin在分支时不会自动更改版本），也许是另一种观点，我不知道......，欢迎任何帮助或消化。
谢谢！
答案 0 :(得分：0)
我尽量避免将内部项目版本保留在父pom的<properties>部分中，因为每次我发布项目时，<version>${project.version}</version>变量都将使用显式版本切换项目如：
<properties>
<project_A.version>1.0.0-SNAPSHOT</projectA.version>
</properties>
存储在父pom中，在项目pom中翻译如： $ {project.version} ，在发布该项目时将变为1.0.1-SNAPSHOT，并将覆盖<project_A.version>来自parent-pom <properties>的版本。因此，只要您不发布项目，将项目版本作为属性保存在像父pom这样的集中位置的这种技巧就是有效的。
这是与分支问题严格相关的问题。
现在，如果您愿意，我可以告诉您有关使用此<properties>替换发布项目的更多信息：
假设您要发布 project_A ，当您开始发布父级时，您将如何处理父pom <projectA.version>中存储的<properties>，这是一个-SNAPSHOT版本pom，对吗？我的意思是，为了发布一个项目，你会首先发布它的所有依赖项及其相关的父pom吗？否则您的项目发布将失败，因为指向父pom的-SNAPSHOT版本。
现在，您正在发布父pom，将 project_A 的-SNAPSHOT版本保留在<properties>内，接下来当您发布 project_A 时，您的项目将引用您父pom的新创建发布版本，哪个父pom发布版本引用 project_A 的-SNAPSHOT版本，仍然没有问题，因为您的父pom保留了真正的版本您的 project_A ，直到 projectA 发布的版本（比如说1.0.0）将引用同一个父pom发布的版本，其中包含1.0.0-SNAPSHOT版本的< strong> project_A ，现在您已经遇到问题，因为您的父pom <properties>保留了错误的信息。
当然，你可以在发布它时破解父pom并存储 project_A 的发布版本，但是这违反了规则而我根本不同意这一点，再加上那个“hack”的其他情况会导致更多问题而不是帮助。
我很抱歉，如果这听起来非常复杂和详细，但我只是想尽可能多地解释现实生活中的情况而不仅仅是理论上的，而且我还需要记住，我需要200多个项目。保持一致。