HK2为什么要重新打包所有内容？

问题描述 投票：14回答：1

我最近从某些工作的项目从泽西岛1切换到泽西岛2。我在《泽西岛2》上遇到的最大烦恼是它使用HK2，出于某种原因，它重新包装了标准的Maven工件。为了避免潜在的烦人的调试问题，我尝试避免从不同的项目中引入相同的类。如果发生这种情况，我会使用Extra Enforcer Rules依赖项中的Ban Duplicate Classes Maven强制执行器规则来破坏构建。

根据前面提到的禁止重复类强制实施者规则，切换到Jersey 2在其工件和我之前使用的标准工件之间引入了以下冲突：

hk2 Artifact                                                Conflicting Artifact
org.glassfish.hk2.external:aopalliance-repackaged:2.3.0-b07 aopalliance:aopalliance:1.0
org.glassfish.hk2.external:bean-validator:2.3.0-b07         com.fasterxml:classmate:0.8.0 (used by org.hibernate:hibernate-validator:5.0.0.Final)
org.glassfish.hk2.external:bean-validator:2.3.0-b07         javax.validation:validation-api:1.1.0.Final
org.glassfish.hk2.external:bean-validator:2.3.0-b07         org.hibernate:hibernate-validator:5.0.0.Final
org.glassfish.hk2.external:bean-validator:2.3.0-b07         org.jboss.logging:jboss-logging:3.1.0.GA
org.glassfish.hk2.external:javax.inject:2.3.0-b07           javax.inject:javax.inject:1

我的解决方案是将标准构件从传递性拉动它们的依赖项中排除，因此仅使用hk2构件。我认为这是更安全的：我不知道hk2工件还会带来什么，如果我将它们排除在外，则可能会丢失（例如，bean验证程序工件似乎正在重新包装至少四个工件）。不利的一面是，首先，我进行了大量的排除，使我的依赖项陷入了混乱，这些依赖项带来了其他无害的API依赖项，例如validation-api。其次，我的工件现在正在导出HK2重新打包的依赖项，而不是我希望导出的实际API类。

最终，我的问题是：

  1. 为什么HK2重新打包所有内容？是否有一些很好的理由？
  2. HK2实际重新包装了什么，我可以改用标准API版本吗？我将如何解决？我已经克隆了HK2项目，并且在弄清楚从哪里开始找到该项目时遇到了一些麻烦。

除非这些问题的实际答案是什么，与HK2背后的开发人员联系的最佳论坛是什么，所以我可以直接问这个问题？我浏览了该网站，虽然找到了一些邮件列表，但没有发现任何明显适合提出此问题的内容。

java maven dependency-management jersey-2.0 hk2
1个回答
12
投票

HK2在OSGi环境中运行，例如GlassFish。不幸的是，大多数标准jar（例如javax.inject，bean-validator和aopalliance）都没有正确的OSGi标头。因此，hk2需要使用OSGi标头重新打包它们，以便它们在该环境中正常工作。

而且，由于GlassFish是Java EE的RI，所以对源代码的可用性提出了某些法律要求，因此，进行一些重新包装是为了满足源代码的要求。

话虽这么说，如果您不在OSGi环境中运行，可以用标准版本替换这些jar（尽管我本人没有尝试过）是安全的]

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.