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

Question

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

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

我的问题是：是否有任何简单的方法可以更改此库的源代码，直到库本身有可用的修复程序？这样做的推荐方法是什么？目前想到两件事：分叉库，进行更改，创建私有 Maven 存储库并将依赖项替换为使用私有存储库的依赖项。如果可以的话，我想避免这种情况。我能想到的另一种方法是分叉库，进行更改，将更新后的库编译成 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>

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

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

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

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

Answer 2

最新的 Spring Facebook 集成库已在 August 中发布：

<dependency>
  <groupId>org.springframework.social</groupId>
  <artifactId>spring-social-facebook</artifactId>
  <version>2.0.2.RELEASE</version>
</dependency>

自 8 月以来，他们的 API 只进行了一些小改动，这不太可能破坏他们 API 与数千个现有应用程序的兼容性。

确实有成千上万的应用程序连接到 Facebook，因此 Facebook 不会（真的不能）允许自己在其 API 中引入重大更改。他们有一个精心设计的版本控制系统，具有回退和向后兼容性等功能，以保护现有的集成。

我了解到您认为您已经找到了该库的可能修复方法。相反，我建议做的是查看导致该特定场景的代码。更有可能的是，您的代码使用 lib 的方式发生了一些微妙的变化，导致了这个 "bug"，而不是 Facebook 犯了这样的错误。

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

Modifying files from external library in Java

java

spring

maven

spring-social-facebook