我目前正试图找到一个合适的工作流来跨多个 Maven 项目执行重构，但我找不到任何令人满意的解决方案。
假设有三个项目。一个名为 common 的项目和两个名为 app1 和 app2 的依赖项目。每个都在一个单独的 Git 存储库中。
现在假设 common 中名为 StringUtils.trim() 的方法应重命名为 StringUtils.getTrimed()。因为此方法被app1 和app2 使用，所以这些项目也需要进行调整。
现在的问题是，向开发团队提供此修改的正确工作流程是什么。鉴于这种情况:一个由大约 10 名开发人员组成的团队使用中央 SCM 服务器和中央 Maven 存储库服务器来托管 Artifact 。
可能的工作流程:
只需将更改提交到 SCM(对于所有三个项目) --> 问题:例如，开发 app1 的开发人员可能没有 checkout 项目 common，而是使用来自中央 Artifact 服务器的二进制文件。当他们从 SCM 获取最新版本的 app1 时，他们的构建将会中断。不好!</p>
除 1 之外，将 app1 的依赖项更改为指向 common 的 SNAPSHOT 版本。 --> 问题:当 app1 开发人员从 SCM 获取最新版本时，如果更新策略是，他们可能不会获得 common 的最新快照设置为 DAILY(默认值)。不好!</p>
除了 2，将 SNAPSHOTS 的更新策略更改为 ALWAYS。 --> 问题:现在，app1 的开发人员将获得 common 的最新 SNAPSHOT 并且一切正常，但前提是在我之前将 SNAPSHOT 部署到 Artifact 服务器将更改提交到 app1!此外，在将 common 项目部署到 Artifact 服务器和我将 app1 提交到 SCM 之间有一个时间段。如果开发人员获取 common 的最新 SNAPSHOT，它将与 SCM 中 app1 的当前版本不兼容，因为我还没有提交对 app1 的更改 还没有。不好!</p>
我能想到的唯一可行的解决方案是跳过 SNAPSHOT 机制并使用版本。这是工作流程:
- 在我的机器上本地更改三个项目后(在任何提交之前)，将 common 的版本从 1.0 增加到 1.1。
- 将 common 提交给 SCM，并将其部署到 Artifact 服务器。
- 仅在部署完成后，将app1 和app2 中的依赖项更改为指向新版本的common 并提交app1 和 app2。
这种方法的问题:我必须做版本管理，所以这只能与整个团队协调并考虑所有依赖项目来完成。此外，我必须等待 common 项目部署到 Artifact 服务器，然后才能将更改提交到 app1 和 app2。
有没有简单灵活的机制，如何进行这样的重构？我希望有人能帮助我。也许我这边也有一些误解。
最佳答案
如果重构是您在示例中建议的类型，我认为您不会找到一种简单的重构方法。您在这里基本上拥有的是从应用程序 1 和 2 到通用的第三方依赖项。而且，正如您可能已经注意到的那样，第三方依赖项不会经常更改其接口(interface)方法的名称，这是有充分理由的 - 这对任何试图更新到最新版本的人来说都是 hell 。
我建议您尽可能保留接口(interface)方法的名称，名称应该有严重错误才能更改(名称说明它做了一些它没有做的事情)反之亦然)。想要将“trim()”更改为“getTrimmed()”并不是这样做的充分理由。
所以，我的建议是:
在通用的内部部分进行您想要的所有重构，保持界面不变。如果你真的必须重命名某些东西，用新名称复制有问题的方法，将旧方法标记为已弃用，并让它们都存活一段时间，直到可以合理地假设每个人都开始使用新的，并停止使用旧的。
关于java - 跨多个项目的 Maven 和重构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12422670/