跨多个项目的Maven和重构

Question

我目前正在尝试找到合适的工作流来跨多个Maven项目执行重构，但是找不到任何令人满意的解决方案。

假设有三个项目。 一个项目称为common项目，两个从属项目app1和app2 。 每个都在单独的Git存储库中。

现在，假设一个通用的名为StringUtils.trim（）的方法应重命名为StringUtils.getTrimed（）。 由于app1和app2使用了此方法，因此也需要对那些项目进行调整。

现在的问题是，什么是向开发团队提供此修改的正确工作流程。 在这种情况下：大约有10个开发人员的团队，他们拥有一个中央SCM服务器和一个中央Maven存储库服务器来托管工件。

可能的工作流程：

1. 只需将更改提交给SCM（针对所有三个项目）->问题：例如，在app1上工作的开发人员可能没有签出项目公用项目，而是使用中央工件服务器中的二进制文件。 当他们从SCM获取最新版本的app1时 ，其构建将中断。 坏！

2. 除1外，将app1的依赖项更改为指向common的SNAPSHOT版本。 ->问题：当app1上的开发人员从SCM获取最新版本时，如果将更新策略设置为DAILY （默认设置），他们可能不会获得最新的SNAPSHOT 通用消息。 坏！

3. 除2外，将SNAPSHOTS的更新策略更改为ALWAYS 。 - >问题：现在，APP1的开发商将获得不俗的最新快照，一切都很好，但前提是快照之前部署到服务器的神器我承诺APP1的变化！ 此外，在将公共项目部署到工件服务器与我将app1提交到SCM之间存在一段时间。 如果开发人员获取common的最新SNAPSHOT，则它将与SCM中的app1的当前版本不兼容，因为我尚未将更改提交到app1 。 坏！

我能想到的唯一可行的解​​决方案是跳过SNAPSHOT机制并使用版本。 这是工作流程：

• 在我的机器上本地更改了三个项目之后（在任何提交之前），将common的版本从1.0增加到1.1。
• 提交共同的供应链管理，并将其部署到服务器的神器。
• 仅在完成部署之后，才更改app1和app2中的依赖项以指向common的新版本，并提交app1和app2 。

这种方法的问题：我必须进行版本管理，因此只能与整个团队协调并考虑所有相关项目来完成。 另外，在将更改提交到app1和app2之前，我必须等待将公共项目部署到工件服务器。

没有任何简单而灵活的机制，如何执行这种重构？ 我希望有人能帮助我。 也许我这边也有一些误解。

Answer 1

我不认为您会发现简单的重构方法，只要它们是您在示例中建议的类型。 您在这里基本上拥有的是从应用1和2到通用的第三方依赖关系。 而且，您可能已经注意到，第三方依赖项不会经常更改其接口方法的名称，这是有充分理由的-任何试图更新到最新版本的人都将陷入困境。

我建议您尽可能保持接口方法的名称高度，以便更改名称（名称指出它执行了某些操作，反之亦然）。 ）。 想要将“ trim（）”更改为“ getTrimmed（）”还不够好。

因此，我的建议是：

在通用的内部部分进行所有所需的重构，使接口保持原样。 如果您确实需要重命名，请使用新名称复制有问题的方法，将旧方法标记为已弃用，并将它们都保留一段时间，直到可以合理地假设每个人都已开始使用新的，并停止使用旧的。

Answer 2

我向您推荐像Sonar（sonarsource.org）这样的开源工具

Answer 3

折旧旧方法名称，然后将调用引用到新方法名称。 然后，您将有一个可以同时使用两者的时间窗口。 然后，要求开发团队每隔X检查一次折旧方法，并在固定时间后将折旧方法放到将来的版本中。

Answer 4

是。 使用版本控制。 对于次要版本升级，请保留旧方法并将其标记为已弃用。 在公共项目的发行说明中记录对界面的更改。