编辑:“反向依赖分析”本来是我搜索的关键字 - 不幸的是我无法正确描述我的问题(也许这与这不是标准的事情有关 - 我实际上什至没有真正的用例为了这)。
假设我有一个典型的收敛问题,并且依赖关系:树告诉我这样的事情:
[INFO] com.my.group:myProject:jar:1.0.1
[INFO] +- org.not.my.group:a-direct-dependency:jar:1.1:compile
[INFO] | \- org.not.my.group:transitive-dependency-A:jar:1.14.0:compile
[INFO] \- org.not.my.group:another-direct-dependency:jar:1.1:compile
[INFO] \- (org.not.my.group:transitive-dependency-A:jar:1.18.0:compile - omitted for conflict with 1.14.0)
有没有办法分析一个中央存储库(也可以使用nexus webgui)来找出是否有一个(更新的)版本org.not.my.group:a-direct-dependency:jar
依赖于传递依赖org.not.my.group:transitive-dependency-A:jar
,但在版本1.18.0而不是1.14.0?
或者一般问:我可以通过中央存储库(或任何远程存储库)找出谁依赖于一个工件,就像我在本地使用它找到它一样?:
mvn dependency:tree -Dincludes=org.not.my.group:transitive-dependency-A:jar:1.18.0 -Dverbose
为了进一步澄清:在上述(虚构的)场景中,我将使用三个“级别”的解决方案来解决收敛问题,而第一个将尽可能是选择,而最新的是“肮脏的修正”。
1 - 对齐版本:如果我的依赖项 - 拥有或第三方 - 直接或传递 - 确实依赖于相同的工件X但定义了不同的版本,我最好尝试在树中找到 X 的较新版本或对X的依赖项其余依赖项的通用版本。这样我假设X的“适当升级”,因为他们可能需要应用代码更改。
2 - 排除依赖项:如果我找不到这样的工件,我将继续尝试排除较低版本,希望具有此排除项的依赖项可以处理较新版本。这需要进行严格的测试,因为我不能保证正确指向版本的较新版本 - 我基本上告诉 maven “这个依赖项也可以与版本的另一个依赖项一起工作,即使因此我不知道这个依赖项的内部设计" - 即使编译成功,我仍然可能会遇到运行时问题。
3 - 使用dependencyManagement:由于使用dependencyManagement可能导致“屏蔽”(隐藏/超越)强制插件的某些收敛问题,我实际上不再认为这是一个解决方案(对于我的设置)......说我遇到了收敛问题并使用dependencyManagement解决了它 - 稍后 - 传递依赖项之一发生变化并导致实施器插件不再能够检测到的类似收敛问题。
旁注:我希望我的英语能更好,这样我就可以更容易地描述这些具体的话题……最终让你们更容易理解我。感谢我已经收到的输入:)