java - 在Java中修改来自外部库的文件

Question

我有一个 Spring Framework 项目，它使用 Maven 来解决依赖关系。该项目依赖于另一个用于 Facebook 登录的 Spring 项目(Spring Social Facebook)。突然，我开始遇到很多错误，因为 Facebook 登录功能因 Facebook API 的更改而中断。该解决方案非常简单，但需要在外部库的文件中进行细微更改 - 将变量类型从整数更改为长整型。

现在我知道了解决方案，但我无法控制这个库。我想自己解决这个问题，直到用修复程序更新库，而不是在系统损坏的情况下等待几天。

我的问题是:有没有什么简单的方法可以更改这个库的源代码，直到库本身有可用的修复程序？这样做的推荐方法是什么？目前想到两件事: fork 库，进行更改，创建私有(private) Maven 存储库并将依赖项替换为使用私有(private)存储库的依赖项。如果可以的话，我想避免这种情况。我能想到的另一种方法是 fork 库，进行更改，将更新后的库编译成 jar 文件并替换 Maven 依赖项以使用 jar 文件。

有没有更好的方法？在这样的(临时)场景中，您会推荐什么？谢谢!

Answer 1

根据工作经验，我在不止一家公司看到过以下做法:

• 修复源代码中的问题
• 用相同的 Maven 坐标再次打包
• 添加一个分类器，通常是companyname-patch(ed)
• 把它放在enterprise Maven repository (即 Artifactory 或 Nexus)

因此，您将从

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
</dependency>

到

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
  <classifier>company-patch</classifier>
</dependency>

这将帮助您保持更多的可追溯性:

• 分类器让内部开发人员和承包商清楚地知道这是公司补丁
• 您确切知道补丁应用到哪个库和哪个版本(因此，部分 self 记录)

此外，它实际上是 Maven classifier 功能的合法且良好的用法。

重复使用相同的 Maven 坐标可能会影响可移植性(我在本地机器上有不同的行为，为什么？)和可维护性(让我们更新这个库，ops.. 它是修补过的，我不知道)，而创建新的 Maven 坐标可能会产生误解(这是什么库？)和错误(我将用这个官方的替换，ops.. 它不再起作用了)。