为什么HK2要重新打包所有东西？

Question

最近，我从泽西岛1转到了泽西2号，从事一些我从事的项目。我在Jersey2中遇到的最大麻烦是它使用了HK2，因为某种原因，它重新打包了标准Maven工件。为了避免潜在的烦人的调试问题，我尽量避免从不同的项目中提取相同的类。如果发生这种情况，我将使用来自额外强制执行规则依赖的禁止重复班 Maven强制执行规则来破坏构建。

根据上述潘基文重复类强制执行规则，切换到泽西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依赖，比如验证-api。其次，我的工件现在正在导出HK2重新打包的依赖项，而不是我希望导出的实际API类。

最后，我的问题是：

1. 为什么HK2要重新打包所有东西？有什么好的理由吗？
2. 什么是HK2真正的重新打包，我可以只使用标准的API版本吗？我该怎么想呢？我已经克隆了HK2项目，我在找出从哪里开始找出这个问题时遇到了一些麻烦。

除了这些问题的实际答案外，什么是与HK2背后的开发人员联系的好论坛，这样我就可以直接问这个问题了。我已经翻阅了网站，虽然我找到了一些邮件列表，但我并没有看到任何明显适合问这个问题的地方。

Answer 1

HK2在OSGi环境中运行，用于GlassFish等产品。不幸的是，大多数标准jars，如javax.inject、bean验证器和aopalliance都没有提供适当的OSGi头。因此，hk2需要用OSGi头重新打包它们，这样它们才能在该环境中正常工作。

另外，由于GlassFish是Java的RI，因此对源代码的可用性提出了某些法律要求，因此所做的一些重新打包是为了满足源代码需求的可用性。

尽管如此，如果您没有在OSGi环境中运行，用标准版本替换这些jars是安全的(尽管我自己还没有尝试过)