在maven项目中，较新版本的依赖项是否会覆盖较旧版本？
如果我有一个maven项目，它对A和B版本2.0有显式依赖，而A对B版本1.0有传递依赖。较新版本的B会覆盖较旧版本吗？我使用了maven Depencdy：解析目标，看起来旧版本的B没有解析。如果A与较新版本的B不兼容怎么办？或者如果A依赖于B版本2.0，而我的项目在运行依赖关系后对B版本1.0有显式依赖：解析目标，那么我看不到B的较新版本。那么如何解决这些依赖关系呢？
当我使用resolve goal时，它会显示依赖关系。但这种依赖关系将在哪个阶段使用？编译、测试、运行时？
共有2个答案
当依赖关系树中引用了多个版本时，maven不会选择较新版本的工件。看着http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html，它似乎从树根中选择了最接近的定义。这意味着主POM中的版本将优先于传递依赖中的版本。因此，如果你的项目依赖于B v1。0和A对B v2具有可传递依赖关系。0，则您的项目将选择B v1。0
更接近依赖树根的版本将是首选。如果两个冲突的版本在树中的深度相同，则第一个（从树的顶部开始）获胜。
这是一个完全愚蠢的规则吗？是的。它唯一的优点是您可以通过将依赖项声明为项目的直接依赖项来强制执行特定版本的依赖项。
因此，在您的情况下，将使用B:2.0，因为它被声明为直接依赖项。如果A不能很好地与B:2.0配合使用，那么，在代码中使用B:1.0，或者选择另一个与A做相同事情但不会引起冲突的库。
-
MVNRepository通常为每个依赖项列出“版本”和“更新”。 如果我发布自己的包，如何指定“更新”版本 Maven在解决传递依赖时使用了哪个依赖项？所以如果我的包依赖于包A，它依赖于包B，版本=1.0，更新=1.1。我会得到哪个版本的B？
-
我用我的真实情况来说明问题。 我使用logback 1.0.1进行日志记录，它包含SLF4J 1.6.4作为依赖项。我还为遗留日志API(Java . util . logging、log4j和commons-logging)使用SLF4J API桥，它们不是显式的依赖关系。这些也必须(最好)是版本1.6.4。 为了使我的pom.xml尽可能整洁和无错误，我想强制这些API桥接器与SLF4J版本相
-
我工作的地方使用Maven，我们有很多内部库。我们尝试以向后兼容的方式进行更改，但有时我们的一个库需要另一个库的较新版本。如果最终产品没有加入较新的库版本，这可能会导致问题。 由于我们有很多库，如果最终产品使用了库A、B和C，而A和B都使用了不同版本的C，那么并不总是使用最新版本的C。从介绍到依赖机制： 依赖项中介--这确定当遇到工件的多个版本时，将使用依赖项的哪个版本。目前，Maven2.0只支
-
问题内容： 我有一个项目，其中两个依赖项使用同一库的不同版本。例如，我的项目具有dependency 和dependency 。和都使用通用的库/依赖项，但版本不同。拥有的版本和具有的版本。所以，现在当我添加和在我的项目依赖，有2个版本，在我的项目的。 我期望在运行时由和引用各个版本。但事实并非如此。不知怎的，当我在我的项目运行测试时，使用的，最好应使用（因为在中，明确指定/加）。所以，它打破了执
-
在Android Studio中，当我使用版本号中的代码时，例如：