2021年4月4日，apache maven发布自己的3.8.1版本；
2021年5月20日，一个倒霉蛋入职新公司，直接下载安装了最新版本的maven，在入职的第一天，开启了自己的折磨之旅。
出现的问题
公司存在online和offline两套maven配置，因为部门存在一些snapshot包的缘故，使用的是offline配置的那套settings.xml。最初没有人引导，根据集团的文档，使用了online配置，在拉取依赖的过程中，发现拉取不到部分plugins，而且项目有很多依赖也找不到，抛出could not resolve异常，于是向同事要了他们的配置，也就是offline配置，但依然出现了问题，大部分的snapshot包拉取不下来。
关键报错
为了不泄露敏感信息，从网上找了个同类型的报错信息贴上来
Could not resolve dependencies for project MassBank2NIST:MassBank2NIST:jar:0.0.2-SNAPSHOT: Failed to collect dependencies at edu.ucdavis.fiehnlab.splash:core:jar:1.8: Failed to read artifact descriptor for edu.ucdavis.fiehnlab.splash:core:jar:1.8: Could not transfer artifact edu.ucdavis.fiehnlab.splash:core:pom:1.8 from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for repositories: [EBI (http://www.ebi.ac.uk/intact/maven/nexus/content/repositories/ebi-repo/, default, releases+snapshots), releases (http://gose.fiehnlab.ucdavis.edu:55000/content/groups/public, default, releases+snapshots)] -> [Help 1]
可以看到这段报错的关键点主要有三段，这也是下手排查问题的关键词
- Could not resolve dependencies for project XXX
- Could not transfer artifact XXX
- Blocked mirror for repositories XXX
前两个问题很常见，都是经常会有人遇到的问题，有许多博客的记录了自己遇到这个问题的解决方法，但是也正是因为太多，导致找到的大部分解决问题的方法都不是这次问题需要的。所有走了很多弯路，也依旧没有解决问题，人也逐渐着急起来。
急躁对于解决问题影响真的很大，可以让明明很简单的问题也半天都找不到思路。
直到休息一段时间让自己平静下来后，搜索第三个关键词，才在stackoverflow上找到了相关的问题，立刻锁定了是maven版本的原因导致的。
在这篇回答里提到，这次的maven升级，它出于安全问题的考虑block掉了所有HTTP协议的repositories，最好的方式是将repositories升级到HTTPS的版本。但是在这篇回答里提供通过设置mirror中mirrorOf和blocked属性的值为false的解决方案对我来说并不打算使用。第一，settings配置是公司通用文件，在其他人使用都没有出问题的情况下，最好不要自己修改，以避免一些未知的风险；第二，blocked属性默认值就是false，所以对于这个方案有效性有所怀疑。最终因为这两个原因没有选择使用这个方法去解决问题。
不过由于知道了是maven版本的问题，一下子整个人都从容了起来，因为再不济直接回退一下版本就能解决一切问题了；这时候转头回想一下，同事们使用了同样的电脑，同样的网络，同样的settings文件，都没有出现问题，应该也是和maven新版本刚发布有关的。事情变得可以理解了。
于是直接来到maven的官网，想找到发布日志或者更新日志，感觉里面会提到原因和解决方案。果然，在maven 3.8.1的release notes中，解决了我的这个疑问。
How to fix when I get a HTTP repository blocked?
当中提到，当由于pom的定义而收到类似文章中开头提到的那种报错结构的话，解决问题的选项是：
upgrade the dependency version to a newer version that replaced the obsolete HTTP repository URL with a HTTPS one,
keep the dependency version but define a mirror in your settings.
要么升级repository要么定义一个mirror，和上文提到的stackoverflow中给出的解决方案一样。所以基于相同的理由，并没有使用这两种方式来解决问题。
最终，还是选择了最简单和快速的那个解决办法：回退maven到上一个版本maven 3.6.3。这时再来尝试拉取依赖就直接成功了，没有出现一点问题。至此，问题解决
结束后的感想
这个问题事后看来十分简单，但是在过程中却是因为焦急的原因导致自己像是无头苍蝇一样乱转，也就造成问题一直没有解决，所以当用周末的时间来处理这个问题的时候，一下子就找到了解决问题的办法。也因此事后产生了提多感想，才写下这篇文章。
当然焦急的原因我也是知道的，是来源于刚入职新公司，想要快速上手项目时却遇到了很多问题。不过与其说是问题，不如说是对于新环境的信息不足，以及对于这种基础简单的问题没有立刻解决所带来的对是否能胜任这份工作的怀疑造成的焦虑。如果顺利的话，在上手开发几个版本之后，应该就能消除这种情绪。
看到maven各个版本的发布时间，想到自己上一次需要配置环境时使用的maven应该3.6.1版本，那时才刚毕业，对maven更加不熟悉，也找不到可用的配置版本，配置里也是一直用的自己的账号，导致后面遇到deploy的场景还要单独找到运维去开权限，这是当时令人印象很深的一件事。不过由于是应届生的缘故，当时似乎没有一丝的心理压力，不过也源自于没有遇到什么大的问题。
最后一点就是对于最新版本工具的使用要保持谨慎的态度，不管是jdk，maven，springboot或者其他的什么东西，虽然不能太多的去使用老版本，因为过老的版本会错过许多新的特性，但是在不了解版本带来的变动的情况下，也不适合在生产环境使用最新或者说比较新的版本，第一是考虑到基础建设可能跟不上，第二是当出现由于版本造成的意料外错误时，对于版本的不熟悉，以及可参考的资料相对较少，会导致比排查问题出现的原因比较困难，这时如果再受到其他因素的干扰，可能很难想到是版本导致的问题。
相关参考
https://stackoverflow.com/questions/66980047/maven-build-failure-dependencyresolutionexception
http://maven.apache.org/docs/3.8.1/release-notes.html