Java 避免使用maven发布插件为下一次开发迭代更新POM版本

我正在用maven发布插件和git发布我的第一个版本。我使用的不是标签，而是发布：分支目标。我同意完整的relase流程，但有一点除外：所有本地依赖项都会自动更新到开发分支中的下一个快照版本

这是我的具体情况：我在一个有20多个maven项目的项目中工作。假设在开发过程中，它们都是快照版本。我想发布maven插件。发布完成后，所有POM版本都已递增，并再次设置为快照。如果我只需要更改一个项目的一行代码（修复一个bug）并发布一个新版本，那么所有项目（默认情况下）都必须在我刚刚更改其中一个项目时再次增加其版本

在我看来，继续开发上一版本的状态（所有版本没有快照）更有意义。在下一次开发迭代中，我只能在我已经更改的项目中手动设置下一个快照版本。在下一个版本中，只有更改的项目将“升级”到新版本，但不是所有项目

我认为这种情况并不例外，但我没有找到如何做到这一点的信息（我也不知道我是否打破了“发布”哲学…）

Somedy知道如何避免将所有POM更新到下一个快照版本，并将POM文件保留为relase版本

---

提前谢谢你

多模块项目的思想是所有模块都是同一发布周期的一部分。即使某些模块不包含任何更改，它们也将成为发布的一部分。有人可能会说：版本很便宜。 与您描述的理想情况相比，好处更大：管理版本和控制模块间的依赖关系更容易。 请记住，主干和分支都应该始终具有快照版本，因为它们是工作副本。如果使用最终版本，发布将失败，因为您不能两次标记同一版本，也不能两次部署（=上载）同一版本。这一点非常重要，因为Maven依赖于最终版本是不可变的定义，即一旦最终版本在本地存储库中可用，Maven将永远不会再次下载

---

因此，如果某些模块的发布周期与整个多模块项目的发布周期不同，则应将其移出此多模块项目（或一次发布所有模块）。

发布单个模块、应用程序或应用程序系统之间的差异在我的幻灯片演示（幻灯片20及以下）中进行了总结

我们有时会将快照版本设置为2.0-snapshot，并将发布版本设置为1.x.y。因此，在开发过程中，我们始终使用2.0-SNAPSHOT，但在发布时，我们选择较旧的版本，例如1.3、1.4，并选择2.0-SNAPSHOT作为下一个发布版本

另外，如果您使用git，请查看。优点之一是它保留了一个开发分支，并且只有版本合并到主分支：

mvn jgitflow:release-start -DreleaseVersion=1.2 -DdevelopmentVersion=2.0-SNAPSHOT
mvn jgitflow:release-finish -DreleaseVersion=1.2 -DdevelopmentVersion=2.0-SNAPSHOT

---

我喜欢这个解决方案，因为它解决了所有与POM之间的依赖关系相关的问题（这是一个非常好的观点）。然而，当您想要发布一个新版本时，您需要1）将您的开发版本（2.0.0-SNAPSHOT）与您的上一个版本（例如1.1）合并。2） 增加发布版本（1.2）并部署它。你是手动完成这个过程，还是可以用maven自动完成？这是用maven使用上面提到的jgitflow插件自动完成的。它会在每次发布后立即自动将发布合并到开发分支。有了这些信息，我的下一个问题是：您知道Maven中是否有办法配置发布插件，以便只发布自上次发布以来已更改的快照？在这种情况下，我的场景可以工作，不是吗？Mavens的范围是当前构建和以前的构建（用于支持增量构建），因此Maven无法检测到与以前版本相比发生了哪些更改。还要注意的是，maven发布插件不支持每个模块标记，因为maven发布插件必须能够按标记进行签出，并再次重建整个（多模块）项目。因此，最可靠的方法是创建一个包含完整多模块的标记。您可以尝试使用-pl来选择可发布的模块，我还没有尝试过，这会使过程更加复杂。问问你自己：这真的很重要吗？我同意你的看法，更新所有POM会更简单…但是说实话，我不喜欢一个模块的不同版本不改变其来源的想法！你不觉得这种情况“肮脏”吗让我们说它不是完美的，但是出错的机会会减少很多。如前所述，这一切都与发布周期有关。如果模块有自己的发布周期，请将其移出多模块项目。但现在，您负责使所有依赖项引用保持最新。我可以挑战您设计您的解决方案：）也就是说：基于修订检测更改；标记时排除未更改的模块。最后，这应该适用于所有的SCM，但我很确定已经很难为单个SCM修复它。正如您所看到的：主要问题是如何正确地指导SCM，Maven可以很容易地遵循