似乎很清楚包含与provided
范围的直接依赖关系。看来,包含runtime
范围的传递依赖也很容易实现。
但是我如何能够将两个间接层的依赖包含在内?
示例:
A --> B --> C
其中A取决于B(编译范围),B取决于C(提供范围)。
我希望A
检索C
(例如:在本地下载jar),无论是通过汇编描述符还是maven-dependency-plugin:copy-dependencies
或其他一些机制。
我已经尝试了两种上述插件的各种选项组合。这两种方法都没有涵盖。它们都获得B
(即使B
已更改为提供的依赖项),以及B
的任何编译范围依赖项,但未提供B的依赖项。
我想我正在尝试做类似于项目的阴影表示但没有解包依赖项的事情。
当然我不想在A的pom中枚举B的所有依赖关系 - 我想隐式地和递归地检索(然后打包)所有依赖关系。
答案 0 :(得分:0)
你将无法做到这一点。它不是maven-assembly-plugin
的限制,而是Maven认为传递依赖的方式。始终省略范围provided
的传递依赖(请参阅文档中的this table)。
有一个关于此问题的公开错误(MNG-2205),但我认为不会很快修复。这实际上是预期的行为,因为provided
依赖于名称,应该在运行时提供。
答案 1 :(得分:0)
尽管Tunaki非常正确,但我找到了一个可行的解决方案,比使用鲜为人知的插件更好(注意:仅适用于Maven< = 3.0.X)
这指定了两个依赖关系块。第一个是正常的编译代码,包括传递代码,它与使用拷贝依赖项相同。除了正常的pom依赖声明之外,第二个块特别提到了B(不幸的是,但至少两个依赖提及都在同一个pom中)并请求它提供的deps:
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>copy-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>get-provided-dependencies</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<resources>
<resource>
<targetPath>${project.build.directory}/lib</targetPath>
<dependencies>
<dependency>
<includeScope>compile</includeScope>
</dependency>
<dependency>
<groupId>some.group</groupId>
<artifactId>artifact_i_call_B</artifactId>
<version>1.0</version>
<includeScope>provided</includeScope>
</dependency>
</dependencies>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
此插件的文档此时可能只存在于存档中,不确定发生了什么: http://web.archive.org/web/20130826193436/http://evgeny-goldin.com/wiki/Copy-maven-plugin