环境：maven项目，使用Nexus私服，jenkins实现代码的编译和打包。
问题分析思路：某周末前，jenkins上的编译打包任务一直正常工作，但周末后突然所有项目都编译失败，报错很一致都是Could not find artifact ******；分析问题前后可能导致问题的变更，以便定位问题
1. 所有项目都出现问题，且gitlab上未发现代码，特别是pom.xml文件的提交记录，可以排除代码问题
2. 分析编译环境maven相关设置，鉴于问题前后都是用的同一个镜像，可以排除编译环境maven配置错误的可能
3. 目前确定的变化就是时间，猜测是否周末时间的变化触发了nexus私服触发了某些清除策略或机制，需要详细分析具体Could not find artifact的包
4. 分析编译过程download的记录日志，发现大量路径类似 Downloaded: http://192.168.10.100:8080/repository/public/，由此分析访问私服网络是没有问题的。
5. 查看日志详细分析未找到的依赖
Downloaded: http://192.168.10.100:8081/repository/public/io/reactivex/rxjava2/rxjava/2.2.19/rxjava-2.2.19.jar (2301 KB at 18115.6 KB/sec) Downloading: http://maven.aliyun.com/nexus/content/groups/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-SNAPSHOT.jar [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] gridnt-common ...................................... SUCCESS [ 2.207 s] [INFO] gridnt-dao ......................................... FAILURE [ 7.685 s] [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 02:36 min [INFO] Finished at: 2022-01-04T08:07:31+00:00 [INFO] Final Memory: 104M/440M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project gridnt-dao: Could not resolve dependencies for project com.gridnt:gridnt-dao:jar:3.1.0: The following artifacts could not be resolved: com.gridnt:project-mqtt-api:jar:dev-9-SNAPSHOT:
Could not find artifact com.gridnt:project-mqtt-api:jar:dev-9-SNAPSHOT in gridnt_repo (http://192.168.10.100:8081/repository/public) -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :gridnt-dao
日志中的关键信息已使用红字标出，含义表达很清晰，在私服仓库中没有这个jar包project-mqtt-api-dev-9-SNAPSHOT.jar。
根据日志中的提示信息，手动构造一下私服上project-mqtt-api-dev-9-SNAPSHOT.jar的访问路径：
Downloaded: http://192.168.10.100:8081/repository/public/io/reactivex/rxjava2/rxjava/2.2.19/rxjava-2.2.19.jar (2301 KB at 18115.6 KB/sec) Downloading: http://maven.aliyun.com/nexus/content/groups/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-SNAPSHOT.jar
理论上应该是http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-SNAPSHOT.jar
打开浏览器，登录nexus私服，访问上述url，结果返回404,表示该jar在私服上不存在
直接在私服上查找，结果可以查找到
此处要注意：我想要下载的【project-mqtt-api-dev-9-SNAPSHOT.jar】，私服上的jar是带有有时间戳【dev-9-SNAPSHOT/project-mqtt-api-dev-9-20220104.093145-1.jar】熟悉maven私服snapshot机制的人到这里基本就找到问题根源了，可惜我对此不是很了解，所以饶了弯路。
6.【弯路，可跳过】以为上述jar包名字没有时间戳也是正确的，走上了错误排查路；因为不是所有私服上的jar都找不到，又先入为主觉得是受时间影响导致大jar包下载失败，所以就归纳分析所有下载失败的jar是否都是update比较早的包，但实际时间上并不存在共性，说明分析方向错误
7. 受同事启发，发现所有下载失败的包都是snapshots仓库的包，release仓库的包没有问题；检查pom.xml配置中私服地址对应仓库组中是否未配置snapshots，实际已配置；调整snapshots仓库顺序，优先查询snapshots仓库，结果问题仍存在。
8. 对比snapshots仓库和release仓库设置，发现snapshots有清除策略，但release没有，因此怀疑是清除策略导致的问题
9. 网上漫搜的过程中突然有人提到使用清除策略后，会导致maven-metadata.xml丢失，然后依赖包下载失败，日志和我的问题类似
10. 返回查看日志，发现project-mqtt-api相关的下载有三个，依次为maven-metadata.xml、*.pom、jar包；对比之前打包成功的日志
-----编译时下载依赖包成功日志
Downloading: http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/maven-metadata.xml
... Downloaded: http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/maven-metadata.xml (2 KB at 36.9 KB/sec) Downloading: http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-20210604.101653-19.pom 2/2 KB Downloaded: http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-20210604.101653-19.pom (2 KB at 78.8 KB/sec) Downloading: http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-20210604.101653-19.jar 360/373 KB 67/67 KB 496/1661 KB 76/121 KB
..... Downloaded: http://192.168.10.100:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-20210604.101653-19.jar (13 KB at 229.7 KB/sec)
----------编译时下载依赖包失败日志
Downloading: http://192.168.8.205:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/maven-metadata.xml ....... Downloading: http://192.168.8.205:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-SNAPSHOT.pom ........ [WARNING] The POM for com.gridnt:project-mqtt-api:jar:dev-9-SNAPSHOT is missing, no dependency information available Downloading: http://192.168.8.205:8081/repository/public/com/gridnt/project-mqtt-api/dev-9-SNAPSHOT/project-mqtt-api-dev-9-SNAPSHOT.jar [ERROR] Failed to execute goal on project gridnt-dao: Could not resolve dependencies for project com.gridnt:gridnt-dao:jar:3.1.0: The following artifacts could not be resolved: com.gridnt:project-mqtt-api:jar:dev-9-SNAPSHOT:
Could not find artifact com.gridnt:project-mqtt-api:jar:dev-9-SNAPSHOT in gridnt_repo (http://192.168.8.205:8081/repository/public) -> [Help 1]
对比两个日志发现：
1）下载依赖包需要依次下载3个问题
2）下载失败从maven-metadata.xml下载失败开始产生的，而不只是缺少jar包，需要研究下maven-metadata.xml
3）成功下载和失败下载对比，.pom和.jar文件的文件名多了一串数字，看起来像时间戳；结合第5步和第6步分析，我们下载依赖jar包失败是因为路径错误，文件名写错了。
11. 研究发现maven-metadata.xml文件通过记录时间戳管理snapshots仓库的版本信息，之前jar和pom文件名称后缀部分的数字就取自maven-metadata.xml文件中的时间戳字段。
此时问题根本在为什么下载maven-metadata.xml失败。根据url访问返回404，该文件不存在。
在nexus下手动查看如下图,未找到maven-metadata.xml文件
12. 解决方案
1）记录上图右下角的信息
com.gridnt project-mqtt-api dev-9-20220104.093145-1
2）登录nexus，创建Rebuild Maven Metadata Files任务（点击上面的Add添加，此图中已完成创建）
3) 新建任务后，Run执行任务，然后刷新snapshots仓库树结构页面，发现maven-metadata.xml文件有了,且记录的时间戳与目录下jar和pom文件名中的时间戳一致。再去执行编译任务下载依赖包成功了。
把所有编译时下载失败的jar(或者所有仓库都执行)都执行任务Rebuild Maven Metadata Files。问题解决了。
总结：遇到问题，最好的定位解决途径就是仔细分析报错日志！
遗留问题：为什么会过一个周末就出现maven-metadata.xml文件丢失的情况，没找到原因，有知道的小伙伴欢迎给
如果以上仍未解决问题，需要自己去看nexus的日志(sonatype-work/nexus/logs/nexus.log),如果有类似下面的日志，
需要去检查一下配置的proxy仓库远程地址是否可以正常访问(最好所有的都检查一下)，如果不能正常访问需要修正地址或者禁用此proxy
