maven的常见问题_Maven常见问题和陷阱

maven的常见问题

喜欢它还是讨厌它（很多人似乎都讨厌它）， Maven是64％的Java开发人员广泛使用的工具（来源– 2014年Java工具和技术前景）。

大多数经验丰富的开发人员已经对Maven感到头疼。通常以困难的方式，用头撞到砖墙上。不幸的是，我感到新的开发人员正在经历同样的艰苦学习过程。

纵观世界各地的主要Java会议，您都找不到任何与Maven相关的会议，这些会议都可以指导您了解基础知识。也许社区认为您应该已经了解它们，就像Java语言本身一样。尽管如此，回收这些知识可能对每个人都是双赢的情况。您或您的队友浪费了多少时间不知道如何处理Maven的特殊性？

如果您正在阅读本文，我还将假设您掌握了Maven的基础知识。如果没有，请查看以下文章：

5分钟内完成Maven
构建生命周期简介

还有很多其他文章。我发现添加自己的内容，重复相同的内容没有任何价值，但是如果我有需要，我可以写一个。让我知道您是否支持！

无论如何，我认为我可以通过指出团队在使用Maven时遇到的主要问题，对其进行解释以及如何解决这些问题来增加一些价值。

为什么这个罐子在我的建筑物中？

由于采用了Maven传递依赖机制，因此所包含库的图可以很快变得很大。

如果您在类路径中看到某些内容，但没有将其放在此处，则很可能是由于传递依赖。您可能需要它，也许不需要。也许您正在使用的库代码的一部分不需要所有这些额外的jar。在这里感觉像是一场赌博，但是如果使用mvn dependency:analyze ，您可能会有一个大概的想法。该命令将告诉您项目实际使用了哪些依赖项。

我主要在这里进行反复试验，排除我认为不需要的内容，然后运行代码以查看一切是否正常。不幸的是，该命令并没有告诉您所使用的依赖项是否确实需要传递依赖项。嘿，如果有人知道更好的方法，请告诉我！

我看不到我的变化！

可能由于多种原因而发生。让我们看一下最常见的：

依赖关系未在本地存储库中构建

您可能具有模块A和模块B。模块B对模块A具有依赖性。对模块B所做的更改在模块A中不可见。

发生这种情况是因为Maven调查了它自己的本地jar存储库，以将其包含在classpath中。如果进行任何更改，则需要将新jar的副本放入本地存储库。您可以通过在更改后的项目中运行mvn install来实现。

依赖版本不正确

可以很简单地更改您正在使用的依赖项的版本，或者弄清楚该依赖项确实很麻烦。当Maven执行依赖关系查找时，它将使用规则“最近定义优先”。这意味着在依赖关系树中，所使用的版本将是最接近您项目的版本。困惑？我也是。让我们尝试一个例子。

您想在项目A使用依赖项Dv1 ，但您正在获取Dv2 ，并且具有以下依赖项树：

A -> B -> C -> Dv1

A -> E -> Dv2

包括D哪个依存关系？ Dv1还是Dv2 ？在Dv2情况下，由于“最近定义优先”规则。如果两个依赖关系版本在依赖关系树中的深度相同，则最重要的是声明中的顺序。

要解决此问题，您可以在A向Dv1显式添加一个依赖Dv1 ，以强制使用Dv1或仅排除Dv2 。

如果使用命令mvn dependency:tree ，它将输出一棵树，其中将包含项目的所有依赖关系和版本。这对于调试此类问题非常有帮助。

远程存储库已覆盖您的更改

公司通常会拥有一个内部Maven存储库，以缓存工件，存储版本或提供您正在处理的项目的最新更改。在大多数情况下，这很有效，但是当您使用SNAPSHOT版本时， Maven始终会尝试获取对该依赖项的最新更改。

现在，您很高兴地在对Project B更改，该更改依赖于Project A 您在本地构建所有内容，然后继续将更改集成到Project A 。某人或某物，上传新的SNAPSHOT版本的Project B 请记住，您所做的更改尚不可见，因为您已将所有内容都保存在本地并且尚未提交到VCS。您对Project A进行的下一个构建将从公司存储库中选择Project B ，而不是从本地存储库中选择Project B