为什么HK2重新包装一切？

Question

对于我工作的一些项目,我最近从Jersey 1换到了Jersey 2.我遇到过泽西2号的最大烦恼是它使用的是HK2,由于某种原因重新打包标准的Maven文物.为了避免潜在的讨厌调试问题,我尽量避免从不同的项目中引入相同的类.我使用Extra Enforcer规则依赖项中的Ban Duplicate Classes Maven强制执行规则来破坏构建(如果发生这种情况).

根据前面提到的Ban Duplicate Classes enforcer规则,切换到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-validator工件似乎重新打包至少四个工件).这样做的缺点是,首先,我对我的依赖项进行了大量的排除,这些依赖项带来了其他无关紧要的API依赖项,例如validation-api.其次,我的工件现在正在导出HK2重新打包的依赖项,而不是我希望导出的实际API类.

最终,我的问题是:

1. 为什么HK2重新包装一切？这有什么好的理由吗？
2. 什么是HK2实际重新包装,我可以只使用标准的API版本吗？我怎么知道这个？我已经克隆了HK2项目,我在找出从哪里开始找到它时遇到了一些麻烦.

除了这些问题的实际答案之外,联系HK2背后的开发人员会有什么好的论坛,所以我可以直接提出这个问题？我查看了网站,虽然我找到了一些邮件列表,但我没有看到任何明显适合提问的问题.

Answer 1

HK2在OSGi环境中运行,用于GlassFish等产品.不幸的是,大多数标准jar如javax.inject,bean-validator和aopalliance都没有合适的OSGi头文件.因此,hk2需要使用OSGi头重新打包它们,以便它们能够在该环境中正常工作.

此外,由于GlassFish是Java EE的RI,因此对源代码的可用性有一些法律要求,因此进行的一些重新打包是为了满足源代码要求的可用性.

话虽这么说,如果你不是在OSGi环境中运行,用标准版本替换这些罐子是安全的(虽然我自己没试过这个)