我最近在想自己为什么elasticsearch会遮蔽并重新定位一些(但不是全部)依赖项。这是项目维护者@kimchy的解释:
阴影部分是有意的,我们在Elasticsearch中使用的阴影库是针对Elasticsearch的所有意图和目的部分,所使用的版本与Elasticsearch公开的内容以及基于库工作原理的内部库使用方式紧密相关(以及版本之间的差异),netty和番石榴就是很好的例子。
顺便说一句,我实际上提供了几罐elasticsearch,其中一个带有未着色的lucene,另一个带有已着色的lucene,我没有问题。虽然不确定如何用Maven做到这一点。我不想提供一个不会掩盖netty / jackson的版本,例如,elasticsearch对它们有很深的使用习惯(例如,对netty的任何先前版本使用即将推出的缓冲改进功能,但当前版本除外)实际使用的内存要多于使用较少的内存)。
- https://github.com/elasticsearch/elasticsearch/issues/2091#issuecomment-7156766
还有一个来自drewr的信息:
阴影对于使我们的依赖关系(尤其是netty,lucene,番石榴)与我们的代码保持接近非常重要,这样即使上游提供程序落后,我们也可以解决问题。我们可能会分发代码的模块化版本,这将有助于解决您的特定问题(例如,#2091),但是目前我们不能简单地删除阴影的依赖项。您可以构建自己的ES本地版本,直到找到更好的解决方案为止。
- https://github.com/elasticsearch/elasticsearch/pull/3244#issuecomment-20125452
因此,这是一个用例。作为说明性示例,下面是如何在elasticsearch的pom.xml(v0.90.5)中使用maven-shade-plugin。这些artifactSet::include行指示它要放入uber JAR中的依赖项(基本上,在生成目标Elasticsearch jar时,将它们解压缩并与Elasticsearch自己的类一起重新打包。(如果您还不知道,则JAR文件是只是一个ZIP文件,其中包含程序的类,资源等,以及一些元数据。您可以提取其中一个文件来查看其组合方式。)
这些relocations::relocation行是相似的,除了在每种情况下它们还将指定的替换应用于依赖项的类-在这种情况下,将它们置于之下org.elasticsearch.common。
最后,本filters节从目标JAR中排除了一些不应包含在其中的东西-例如JAR元数据,蚂蚁构建文件,文本文件等,它们打包在一起并具有某些依赖项,但不属于超级JAR。
org.apache.maven.plugins
maven-shade-plugin
2.1
package
shade
true
com.google.guava:guava
net.sf.trove4j:trove4j
org.mvel:mvel2
com.fasterxml.jackson.core:jackson-core
com.fasterxml.jackson.dataformat:jackson-dataformat-smile
com.fasterxml.jackson.dataformat:jackson-dataformat-yaml
joda-time:joda-time
io.netty:netty
com.ning:compress-lzf
com.google.common
org.elasticsearch.common
gnu.trove
org.elasticsearch.common.trove
jsr166y
org.elasticsearch.common.util.concurrent.jsr166y
jsr166e
org.elasticsearch.common.util.concurrent.jsr166e
org.mvel2
org.elasticsearch.common.mvel2
com.fasterxml.jackson
org.elasticsearch.common.jackson
org.joda
org.elasticsearch.common.joda
org.jboss.netty
org.elasticsearch.common.netty
com.ning.compress
org.elasticsearch.common.compress
*:*
META-INF/license/**
META-INF/*
META-INF/maven/**
LICENSE
NOTICE
/*.txt
build.properties