Maven 如何解决传递依赖的版本冲突？最近胜策略
我终于习惯了在我的项目中没有任何已使用的未声明或未使用的已声明依赖项。尽管跟踪 dependency:analyze... 中列出的未使用的已声明运行时/测试依赖项非常困难，但只需在 pom.xml 中对它们编写注释，或者以其他方式管理它们以了解测试或运行时需要它们。
但解决版本冲突的方法我还是不清楚。关于传递依赖。
最近获胜策略到底是如何运作的？何时使用一个版本而不是另一个版本？
如果您使用版本号声明已使用的未声明依赖项 - 它总是获胜
如果没有显式指定依赖项版本， Maven 无法解析任何版本 关于此依赖关系可能出现的冲突（很奇怪，但写成 here)
如果您不声明未声明的使用依赖项，它会从最接近的级别（最近获胜策略）中选择一个传递依赖项，如果冲突位于同一级别，那么它会以某种方式决定在版本 A 与版本 B 之间...也许处理依赖关系时遇到的第一个获胜
I just finally got used to not having any Used undeclared or Unused declared dependencies in my projects. Although it is very hard to track Unused declared runtime/test dependencies that are listed in dependency:analyze... One just must write comments to them in pom.xml or otherwise manage them to know that they are needed for testing or runtime.
But the way of resolving version conflict is still unclear to me. Regarding transitive dependencies.
How does the nearest-wins strategy work exactly? When is one version used over another version ?
If you declare the Used undeclared dependency with a version number - it always wins
If one doesn't specify dependency version explicitly, Maven cannot resolve any version
conflicts that may arise regarding this dependency (weird, but written here)If you don't declare Undeclared used dependency, it chooses a transitive dependency from the closest level (nearest-wins strategy) and if the conflict is on the same level then it somehow decides between version A over version B ... Maybe the first one it comes to when processing the depenencies wins
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为依赖关系解析的工作方式与您描述的完全相同。
我还认为，如果您使用
（引用自 maven 官方网站：
这是默认范围，如果未指定则使用。编译依赖项在项目的所有类路径中都可用。此外，这些依赖关系会传播到依赖项目。
此范围仅用于该部分中 pom 类型的依赖项。它指示指定的 POM 应替换为该 POM 部分中的依赖项。由于它们被替换，具有导入范围的依赖项实际上并不参与限制依赖项的传递性。
I think the dependency resolution works the exact same way you described.
I also think your life would be much easier if you use the
<scope>child tag to your<dependency>as quoted from the maven official website:
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM's section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
有一些依赖管理文档的链接：
http://maven .apache.org/guides/introduction/introduction-to-dependency-mechanism.html
（“依赖范围”部分中的导入表）
德国期刊中有一篇神文描述了依赖关系的解决 - 这里是文章的 bibtex 参考： http://www.bibsonomy.org/bibtex/2ef10bb1bc1be7806bc3fba53417bbd5f/funthomas424242
sonatype 书中有一节关于依赖插件的部分：
http://www.sonatype.com/books /mvnex-book/reference/optimizing-sect-dependency-plugin.html
我希望它有帮助。
There are some links to documentation of dependency management:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
(importend table in section "dependency scope")
There are a god article in a german journal which describe the solving of dependencies - here are the bibtex ref of article: http://www.bibsonomy.org/bibtex/2ef10bb1bc1be7806bc3fba53417bbd5f/funthomas424242
There are a section about the dependency plugin in the sonatype book at:
http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.html
I hope it was helpfull.