How does Maven resolve version conflicts of transitive dependencies ? nearest-wins strategy

白昼怎懂夜的黑 提交于 2020-01-21 02:36:08

问题


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


回答1:


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:

  1. compile: 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.
  2. provided: This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
  3. runtime This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
  4. test: This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
  5. system: This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
  6. import: (only available in Maven 2.0.9 or later) 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.



回答2:


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.



来源:https://stackoverflow.com/questions/6283891/how-does-maven-resolve-version-conflicts-of-transitive-dependencies-nearest-wi

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!