Maven 虐我千百遍，我待 Maven 如初恋！，mongodb 教程
私服，就是公司内部局域网的一台服务器而已，你想一下，当你的工程 Project-A 依赖别人的 Project-B 的接口，怎么做呢？没有 Maven 的时候，当然是 copy Project-B jar 到你的本地 lib 中引入，那么 Maven 的方式，很显然需要其他人把 Project-B deploy 到私服仓库中供你使用。因此私服中存储了本公司的内部专用的 jar！不仅如此，私服还充当了中央仓库的镜像，说白了就是一个代理！
中央仓库：该仓库存储了互联网上的 jar，由 Maven 团队来维护，比如地址是类似这样的：https://repo1.maven.org/XXXX。
需要更多大厂面试资料的话也可以[点击直接进入，免费获取！](
)暗号：CSDN
[](
)Q2：关于< dependency >的使用
依赖管理
其实这个标签揭示了 jar 的查找坐标：groupId、artifactId、version。
一般而言，我们可以到私服上输入 artifactId 进行搜索，或者到http://search.maven.org/、http://mvnrepository.com/上进行查找确定坐标。
version 分为开发版本（Snapshot）和发布版本（Release），那么为什么要分呢？
在实际开发中，我们经常遇到这样的场景，比如 A 服务依赖于 B 服务，A 和 B 同时开发，B 在开发中发现了 BUG，修改后，将版本由 1.0 升级为 2.0，那么 A 必须也跟着在 POM.XML 中进行版本升级。过了几天后，B 又发现了问题，进行修改后升级版本发布，然后通知 A 进行升级…可以说这是开发过程中的版本不稳定导致了这样的问题。
Maven，已经替我们想好了解决方案，就是使用 Snapshot 版本，在开发过程中 B 发布的版本标志为 Snapshot 版本，A 进行依赖的时候选择 Snapshot 版本，那么每次 B 发布的话，会在私服仓库中，形成带有时间戳的 Snapshot 版本，而 A 构建的时候会自动下载 B 最新时间戳的 Snapshot 版本！
[](
)Q3：既然 Maven 进行了依赖管理，为什么还会出现依赖冲突？处理依赖冲突的手段是？
依赖的版本？
首先来说，对于 Maven 而言，同一个 groupId 同一个 artifactId 下，只能使用一个 version！
根据上图的依赖顺序，将使用 1.2 版本的 jar。
现在，我们可以思考下了，比如工程中需要引入 A、B，而 A 依赖 1.0 版本的 C，B 依赖 2.0 版本的 C，那么问题来了，C 使用的版本将由引入 A、B 的顺序而定？这显然不靠谱！如果 A 的依赖写在 B 的依赖后面，将意味着最后引入的是 1.0 版本的 C，很可能在运行阶段出现类（ClassNotFoundException）、方法（NoSuchMethodError）找不到的错误（因为 B 使用的是高版本的 C）！
这里其实涉及到了 2 个概念：依赖传递（transitive）、Maven 的最近依赖策略。
依赖传递：如果 A 依赖 B，B 依赖 C，那么引入 A，意味着 B 和 C 都会被引入。
Maven 的最近依赖策略：如果一个项目依赖相同的 groupId、artifactId 的多个版本，那么在依赖树（mvn dependency:tree）中离项目最近的那个版本将会被使用。（从这里可以看出 Maven 是不是有点小问题呢？能不能选择高版本的进行依赖么？据了解，Gradle 就是 version+策略）
现在，我们可以想想如何处理依赖冲突呢？
想法 1：要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？
使用< dependencyManagement> [这种主要用于子模块的版本一致性中]
想法 2：在依赖传递中，能不能去掉我们不想依赖的？
使用 [在实际中我们可以在 IDEA 中直接利用插件帮助我们生成]
想法 3：既然是最近依赖策略，那么我们就直接使用显式依赖指定版本，那不就是最靠近项目的么？
使用< dependency>
[](
)Q4：引入依赖的最佳实践，提前发现问题！
在工程中，我们避免不了需要加一些依赖，也许加了依赖后运行时才发现存在依赖冲突在去解决，似乎有点晚！那么能不能提前发现问题呢？
如果我们新加入一个依赖的话，那么先通过 mvn dependency:tree 命令形成依赖树，看看我们新加入的依赖，是否存在传递依赖，传递依赖中是否和依赖树中的版本存在冲突，如果存在多个版本冲突，利用上文的方式进行解决！
[](
)Q5：Maven 规范化目录结构
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论