使用Java从外部库修改文件 [英] Modifying files from external library in Java

问题描述

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

I have a Spring Framework project which uses Maven for resolving dependencies. The project has a dependency to another Spring project (Spring Social Facebook), which is used for Facebook login. Suddenly, I started to get a lot of errors because the Facebook login functionality broke due to changes in the Facebook API. The solution is extremely simple but requires a minor change within the external library's files - changing a variable from the type integer to long.

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

Now I know the solution, but I don't have control over this library. I would like to fix this problem myself until the library is updated with the fix, rather than waiting around for days with a broken system.

我的问题是:在库本身有可用的修复程序之前，有什么简便的方法可以更改此库的源代码?建议这样做的方法是什么?当前想到两件事:分叉库，进行更改，创建私有Maven存储库，并将依赖项替换为使用私有存储库的依赖项.如果可以的话，我想避免这种情况.我能想到的另一种方法是，分叉库，进行更改，将更新的库编译到jar文件中，并替换Maven依赖项以使用jar文件.

My question is: is there any easy way in which I can make a change to the source code of this library until a fix is available in the library itself? What is the recommended way of doing this? Two things currently come to mind: forking the library, make the change, and create a private Maven repository and replace the dependency with one that uses the private repository. If I can, I'd like to avoid that. The other way I can think of, would be to fork the library, make the change, compile the updated library into a jar file and replace the Maven dependency to use the jar file.

有更好的方法吗?在这样的(临时)方案中，您会推荐什么?谢谢！

Is there a better way? What would you recommend in a (temporary) scenario like this? Thanks!

推荐答案

从工作经验来看，在多家公司中，我看到了以下方法:

From working experience, in more than one company I have seen the following approach:

• 修复源代码中的问题
• 使用相同的Maven坐标再次打包
• 添加一个分类器，通常是companyname-patch(ed)
• 将其放入企业Maven存储库(即Artifactory或Nexus)
>

• Fix the issue in the source code
• Package it again with the same Maven coordinates
• Add a classifier, which was usually companyname-patch(ed)
• Put it in the enterprise Maven repository (i.e. Artifactory or 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>

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

This would help you to keep more traceability:

• 分类器使内部开发人员和承包商都清楚这是公司补丁
• 您确切知道该修补程序应用于哪个库和哪个版本(因此，部分会自我记录)

此外，它实际上是Maven classifier功能的合法使用.

Furthermore, it is actually a legal and good usage of the Maven classifier feature.

重用相同的Maven坐标可能会影响可移植性(我在本地计算机上的行为不同，为什么?)和可维护性(让我们更新此库，操作..它是已修补的库，我不知道)，而创建新的Maven坐标可能会造成误解(这是什么库?)和错误(我将由这个正式的人代替，操作.它不再起作用了.)

Reusing the same Maven coordinates may affect portability (I have a different behavior on my local machine, why?) and maintainability (let's update this library, ops.. it was the patched one, I didn't know), while creating new Maven coordinates may create misunderstanding (what's this library?) and errors (I will replace by this official one, ops.. It doesn't work anymore).

这篇关于使用Java从外部库修改文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！