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

我最近将某些工作从 Jersey 1切换到 Jersey 2。我在《 Jersey 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类。

最终，我的问题是:

HK2为什么要重新打包所有内容？这有什么充分的理由吗？

HK2实际重新包装了什么，我可以改用标准API版本吗？我将如何解决？我已经克隆了HK2项目，并且在弄清楚从哪里开始找到该项目时遇到了一些麻烦。

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

最佳答案

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

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

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