我最终分别构建了该项目,并将此版本移至另一个名称空间。这显然并不少见。例如,Hibernate将CGLIB保持在自己的名称空间中,以避免由于API的更改而引起的版本冲突。
当我使用的项目也用于另一个依赖关系时,第一个建议的解决方案遇到了问题。 普通的 版本在班级路径上导致了由于命名冲突而导致非常奇怪的行为。
第二和第三个建议与第一个建议相似。此外,我与其他版本的依赖性兼容。
即使听起来很痛苦:即使您只更改几行代码,也必须摆脱命名空间并提供独立的构建。
题
我在使用的较大应用程序框架中发现了一个小错误。固定只需要在一个类中更改两行。我解决了问题,并将更改推向了项目的存储库。
但是,我明天需要释放。因此,我迫不及待地等到库发布新版本。我想知道将修补版本集成到我的项目中的最佳方法是什么:
构建项目:我觉得很困难,我什至无法正确构建它,因为在快照存储库中破坏了如此多的单元测试,即使没有单位测试,我也不会走得很远,因为我显然缺少一些找不到的依赖项在Maven Central。另外,我需要将固定版本发送给其他所有开发人员,因为在Maven Central上找不到它。 (我们在网上工作,我们没有自己的联系。)
在我的项目中添加一个新模块,在该模块中,我保留了我已修复的课程的副本。然后,我将此模块添加为所有应该使用类的Overriden版本的模块的依赖关系。但是,JVM如何确定其实际加载哪个类?它会找到两个 罐- 包含具有相同名称的类的文件。它实际上会加载哪一个?如果我可以做这项工作,这将使我能够将课程的修改版本与项目集成在一起,以便可以将补丁程序与项目一起分发,并且一旦错误修复,我就可以简单地删除模块。
我将修改后的类文件包括在受影响的模块中。到目前为止,这是对我来说最简单的解决方案,因为JVM将始终首先从同一罐子加载类。 (我是对的吗?至少那是我在测试中观察到的。)
感谢您对此的任何输入。
解决方案
我最终分别构建了该项目,并将此版本移至另一个名称空间。这显然并不少见。例如,Hibernate将CGLIB保持在自己的名称空间中,以避免由于API的更改而引起的版本冲突。
当我使用的项目也用于另一个依赖关系时,第一个建议的解决方案遇到了问题。 普通的 版本在班级路径上导致了由于命名冲突而导致非常奇怪的行为。
第二和第三个建议与第一个建议相似。此外,我与其他版本的依赖性兼容。
即使听起来很痛苦:即使您只更改几行代码,也必须摆脱命名空间并提供独立的构建。
其他提示
我认为,由于几个原因,将项目的依赖性转移到自定义名称空间并不是最佳的:
我同意使用Jitpack的工作流程是最好的解决方案。我写了一篇博客文章,其中包含详细指南,只需几分钟的开销: https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/
访问 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>