喜欢它还是讨厌它（很多人似乎都讨厌它）， 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
该罐子不包括在分发中！
为了增加一些混乱，让我们谈谈范围。 Maven有四个作用域： compile ， provided ， runtime和test 。 每个依赖项都有一个范围，该范围为您的应用程序定义了不同的类路径。
如果缺少某些内容，并假设正确定义了依赖项，则问题很可能出在范围之内。 compile安全考虑，请使用compile范围（这是默认设置）。 命令mvn dependency:analyze和mvn dependency:tree在这里也可以为您提供帮助。
找不到工件！
啊，可怕的是“无法解决依赖关系……无法找到工件”。 这就像Java NPE！ 发生这种情况的原因有很多。 还有其他一些明显的证据，但无论如何还是要调试的。 我通常会按照以下清单尝试解决此问题：
- 检查依赖项是否正确定义
- 检查您是否指向存储依赖项的正确远程存储库
- 检查远程存储库是否真正拥有依赖项！
- 检查您是否拥有最新的pom.xml文件
- 检查罐子是否损坏
- 检查公司存储库是否正在缓存Internet存储库，并且没有发出获取新库的请求
- 检查依赖项定义是否被某些内容覆盖。 使用
mvn help:effective-pom进行构建项目的实际Maven设置 - 不要使用-o
结论
Maven并不是一个完美的工具，但是，如果您了解一些技巧，它将帮助您并节省调试构建问题的时间。 还有其他方法可以解决其中一些问题，但是我所掌握的知识不足以表达我对这些问题的看法。
无论如何，大量的项目使用Maven作为构建工具，我相信开发人员应该了解他们的构建工具，以便能够在日常工作中表现更好。 希望这篇文章对您有用。
随时发布此处未涵盖的任何其他问题。 不幸的是， Maven有时似乎充满了惊喜。
最后一条建议：永远不要信任IDE！ 如果它可以在命令行上运行，那就是IDE的问题！
翻译自: https://www.javacodegeeks.com/2014/09/maven-common-problems-and-pitfalls.html
)
