Question

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

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

我的问题是：有没有简单的方法可以更改此库的源代码，直到库中有可用的修复程序？这样做的推荐方法是什么？目前我想到两件事：分叉库，进行更改，并创建一个私有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坐标可能会影响可移植性（我在本地计算机上有不同的行为，为什么？）和可维护性（让我们更新这个库，操作...它是修补过的，我没有＆＃39 ;知道），虽然创建新的Maven坐标可能会产生误解（这个库是什么？）和错误（我将替换为这个官方的，操作......它不再起作用了。）

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的方式的一些细微变化更有可能导致这个“错误”，而不是Facebook犯这样的错误。

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

2 个答案: