热修复第三方库依赖项中的错误

时间:2013-11-07 22:58:00

标签: java maven release hotfix

我在一个更大的应用程序框架中发现了一个小错误,我正在使用它。修复只需要在一个类中更改两行。我修复了问题并将更改推送到项目的存储库。

但是,我需要明天发布。因此,我不能等到库发布新版本。我想知道将修补版本集成到我的项目中的最佳方法是什么:

  • 构建项目:我发现这很困难,我甚至无法正确构建它,因为在快照存储库中打破了很多单元测试,即使没有单元测试,我也没有走得太远,因为我显然缺少一些在Maven Central中找不到的依赖项。此外,我需要将固定版本发送给其他所有开发人员,因为它无法在Maven Central上找到。 (我们在网上工作,我们没有自己的Nexus。)

  • 在我的项目中添加一个新模块,我保留了我修复过的类的副本。然后我将此模块添加为应该使用该类的重写版本的所有模块的依赖项。但是JVM如何确定它实际加载哪个类?它将找到两个包含具有相同名称的类的 jar 文件。实际加载哪一个?如果我可以完成这项工作,这将允许我将类的修改版本与我的项目集成,以便我可以将补丁与项目一起分发,一旦错误得到修复,我就可以简单地删除模块。

  • 我将修改后的类文件包含在受影响的模块中。到目前为止,这对我来说似乎是最简单的解决方案,因为JVM总是首先从同一个jar加载类。 (我是对的吗?至少这是我在测试中观察到的。)

感谢您提供任何意见。

3 个答案:

答案 0 :(得分:2)

我最终单独构建项目并将此版本移动到另一个名称空间。这显然不是那么罕见。例如,Hibernate将cglib保存在自己的命名空间中,以避免因API更改而导致的版本冲突。

  • 第一个建议的解决方案有一个问题,当我使用的项目也被用于另一个依赖项,导致我的修改版本和普通版本都在类路径上导致什么由于命名冲突导致的非常奇怪的行为。

  • 第二个和第三个建议与第一个建议有类似的问题。此外,我打破了与其他版本的依赖项的兼容性。

即使听起来很痛苦:即使您只更改了几行代码,移出​​命名空间并提供单独的构建也是必须的。

答案 1 :(得分:1)

TL; DR;

访问https://jitpack.io并阅读其工作原理

解决问题的步骤

假设第三方库在github上,只需克隆项目并修复它。

然后使用https://jitpack.io。 JitPack从您的仓库创建一个.jar(修改代码的地方)并为您生成一个依赖项

<dependency>
    <groupId>GITHUB_USER</groupId>
    <artifactId>REPOSITORY</artifactId>
    <version>COMMIT</version>
</dependency>

您还需要显式添加此远程存储库

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>
  • 快速解决方案
  • 简单易行
  • 简单撤消

答案 2 :(得分:1)

我认为将项目的依赖项移动到自定义命名空间并不是最佳的,原因如下:

  • 您的修改可能不会被发送回依赖项的原始开发人员。
  • 很难跟上新的依赖版本,因此不再有错误修正,没有新功能,也没有来自第三方开发者和贡献者的漏洞修复。
  • 我的经验是,随着时间的推移它会被遗忘如何为什么自定义命名空间依赖关系被修改。这将导致项目的这一部分不仅被弃用,而且也不可触及,因为没有人知道更换它时会发生什么破坏。

我同意使用Jitpack的工作流程是最佳解决方案。我写了一篇博文,其中包含一个详细的指南,只需几分钟的开销即可:https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/

相关问题