跨多个项目的Maven和重构

Question

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

假设有三个项目。一个名为 common 的项目和两个名为 app1 和 app2 的依赖项目。每个都在一个单独的Git存储库中。

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

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

可能的工作流程：

1. 只需将更改提交给SCM（适用于所有三个项目） - ＆GT;问题：例如，在 app1 上工作的开发人员可能没有签出项目 common ，但是正在使用来自中央工件服务器的二进制文件。当他们从SCM获取最新版本的 app1 时，他们的构建将会中断。 BAD！

2. 除1之外，更改 app1 的依赖关系以指向 common 的SNAPSHOT版本。 - ＆GT;问题：当开发 app1 的开发人员从SCM获取最新版本时，如果更新策略设置为<，他们可能无法获得 common 的最新SNAPSHOT em> DAILY （这是默认值）。 BAD！

3. 此外，2，将SNAPSHOTS的更新政策更改为 ALWAYS 。 - ＆GT;问题：现在， app1 的开发人员将获得 common 的最新SNAPSHOT，一切正常，但只有在我提交更改之前将SNAPSHOT部署到工件服务器到 app1 ！此外，在 common 项目部署到工件服务器和我将 app1 提交到SCM之间有一段时间。如果开发人员获取 common 的最新SNAPSHOT，它将与SCM中当前版本的 app1 不兼容，因为我还没有将更改提交给 app1 还没有。 BAD！

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

• 在我的机器上本地更改三个项目之后（在任何提交之前），将 common 的版本从1.0增加到1.1。
• 将 common 提交给SCM并将其部署到工件服务器。
• 仅在部署完成后，更改 app1 和 app2 中的依赖项以指向新版本的 common 并提交 app1 和 app2 。

这种方法的问题：我必须进行版本管理，所以这只能与整个团队协调并考虑所有依赖项目。此外，在将更改提交到 app1 和 app2 之前，我必须等待 common 项目部署到工件服务器。< / p>

是不是有任何简单灵活的机制，如何执行这样的重构？我希望有人可以帮助我。也许我身上也有一些误解。

Answer 1

我不认为你会发现一种简单的重构方法，如果它们是你在你的例子中建议的类型。你在这里基本上拥有的是来自app 1＆amp; amp;的第三方依赖。 2到常见。并且，正如您可能已经注意到的那样，第三方依赖项并不经常更改其接口方法的名称，这是有充分理由的 - 对于任何尝试更新到最新版本的人来说都是完美的。

我建议你尽可能高地保留接口方法的名称，名称应该有一些严重的错误，以便更改（名称表明它做的事情不是或反之亦然）。想要将“trim（）”改为“getTrimmed（）”是不够的理由。

所以，我的建议是：

在共同的内部部分中执行所需的所有重构，保持接口不变。如果你真的需要重命名某些内容，请使用新名称复制相关方法，将旧版本标记为已弃用，并将它们保持活动一段时间，直到假定每个人都已开始使用为止是合理的新的，并停止使用旧的。

Answer 2

我建议您使用像Sonar（sonarsource.org）这样的OpenSource工具

Answer 3

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

Answer 4

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