开发日志：dependencies.dependency.version is missing 和 Could not resolve dependencies for project 问题

一、问题一：dependencies.dependency.version is missing

1.1 问题分析

问题形式：dependencies.dependency.version for XXXXX(依赖名) is missing

        这是因为找不到依赖的版本号导致的。

        首先定位项目pom.xml中的问题依赖所在位置。

1.1.1 方法一（直接手动续写信息）

        由图可知，红框内的依赖只有依赖名，和定位信息。并没有报错中提示版本信息。所以自然想到第一个办法：手动写入版本信息

<version>对应的版本号</version>
<scope>provided</scope>
<type>pom</type>

        简单说明一下：

        <version>:
        作用: 指定依赖的版本号。Maven 会根据这个版本号去查找并下载相应的依赖。

        <scope>:
        作用: 定义依赖的范围，即在构建的不同阶段如何处理该依赖。 provided 是 scope 的一个选项，表示该依赖在编译时可用，但在部署时假定已经存在（例如在服务器上）。这意味着它不会被打包进最终的应用程序中，适用于那些在运行环境中已经提供的库，比如 Servlet API。

        我处理的这个项目文件时open-api，为整个系统提供依赖的。

        <type>:
        作用: 指定依赖的类型，默认是 jar。当 <type> 设置为 pom 时，表明这不是一个普通的依赖库，而是一个 POM（Project Object Model）文件，通常用于导入另一个 Maven 项目的依赖管理信息。这种类型的依赖主要用于父项目或者 BOM（Bill of Materials）文件中。

注意事项：

• <scope> 和 <type> 的组合通常用于特殊的场景，例如导入依赖管理信息。
• 如果 <type> 设置为 pom，那么 <scope> 通常也会被设置为 import，这通常出现在 <dependencyManagement> 块内。
• 如果 <scope> 被设置为 import 并且 <type> 设置为 pom，则表明该项目将继承来自另一个 POM 文件的依赖管理信息。

1.1.2 方法二 （在父项目的dependencyManagment中添加对应的依赖机器版本）

        在方法一中我们提到了“父项目”，这个可以理解为一个大家庭中的大家长、大族长，其他的小项目就是其中的成员，平时的资源（依赖）是由大家长（父项目）来统一调度，成员（子项目）来领取（调用）一下就可以了。

        父项目的pom中指定了dependencyManagement标签
这个标签很重要，这里涉及一个概念，此标签的用处及与dependency的区别。
dependencymanagement的作用在于声明依赖，但其并不引用。只是表示了一个抽象，你可以做哪些事，但你还没有做。

        举了例子dependency表示引入了某个依赖，一个或duogejar，可以在其中忽略具体的版本，因为他会从dependencymanagement中获取他应该有的版本。

        在该图中，只有<dependencies>来注入依赖

        那么我的问题就是：想引入 atoikos-util 的功能，但我在父项目的dependencyManagement中没有声明atoikos-util 及其版本。所以在子项目中，如果对依赖不加入version的话，就会提示version is missing。

        所以最后如下图所示，添加即可。

        参考资料：https://segmentfault.com/a/1190000025218281

二、 问题二：Could not resolve dependencies for project

2.1 问题分析

        问题形式：Could not resolve dependencies for project com.asiainfo.dde:open-api:jar:2.0.0-AHUI: 

        但是在我本地的Maven仓库找到了对应的依赖和相应的版本，可是在 install 的时候还是没有能够扫描的到。

        这是因为，maven在刷新识别的时候会分为线上的仓库识别，和本地仓库识别。显然，这是时因为，线上仓库识别不成功而没有再识别本地仓库中的依赖，才导致找不到依赖。

        所以既然本地仓库有，线上仓库又走不通，所以显然我们可以优先扫描本地仓库的依赖。

        补充：在实际开发工作中，我们不仅要使用网上常见的依赖，而且还可能使用公司自研的依赖。所以在此pom.xml文件中也会有配置公司的maven仓库的内容。（而我们这此处的问题就是与公司依赖有关系。）

        而在个人开发的情况下，我们更多的是使用网络上开放的maven仓库，例如Alibaba的maven仓库等，这个包含了不少常用的依赖，再加上是国内的路径使得依赖的下载速度会很快。所以，这也是很多配置maven的时候选择了Alibaba的maven仓库的原因。

        但是这里的依赖拉取是使用逻辑我并没有理清，欢迎路过的大神可以帮忙解答一下。

        项目在install开始后，需要扫描依赖，那么去哪里扫描？

        在线上仓库扫描，有的就直接下载下来到本地仓库，等全部的依赖都下载准备完毕时，install完成。当遇到线上仓库没有找到相应的依赖，例如此处的公司依赖，在Alibaba的maven仓库里是找不到的，所以会报错 找不到依赖。

        在本地仓库中扫描，全部都具备那就直接完成install，如果缺少一部分依赖，这时该去哪个仓仓库下载？

       如何知晓，每次扫描的时候都是通过哪个地址去访问的哪个仓库的呢？

2.1.1 方法一（在maven配置文件中修改）

        在maven的setting文件中配置文件源

 <!--阿里maven源时配置-->
    <mirror>
      <id>alimaven</id>
      <name>aliyun maven</name>
      <url>
        http://maven.aliyun.com/nexus/content/groups/public/
      </url>
      <mirrorOf>central</mirrorOf>
    </mirror>
    <!--使用本地源时配置-->
    <mirror>
      <id>central</id>
      <mirrorOf>*</mirrorOf>
      <name>central</name>
      <!--刚刚选定的maven本地仓库位置-->
      <url>D:\maven 3.9.3\repository</url>
    </mirror>

<!-- 我的本地仓库位置 -->
  <localRepository>D:\maven 3.9.3\repository</localRepository>

        再次刷新依赖，执行package操作，不出现报错即成功

2.1.2 方法二（修改_remote.repositories文件）、

        在本地仓库中找到对应的依赖，在相应的版本中找到_remote.repositories文件。

        此处以“backport-util-concurrent”为例，在3.1版本文件中，有个_remote.repositories文件，打开

        由此可以看出，依赖在下载时是优先从 alimaven （Alibaba maven仓库）中下载，其次是 maven-public-dde （公司maven仓库）中下载。

        所以，我们可以，将 alimaven= 和 maven-public-dde= 删掉

        或者是，将整个_remote.repositories 文件删掉。

参考来源：https://blog.csdn.net/qq_43233225/article/details/131955347

三、 总结

        为了解决这个问题花费很多的时候，也是查找了不少资料，最后发现问题的原因其实并不难。甚至是简单的一个操作可以解决。

        但是，其中困难的就是，一个问题会有几重的表现形式，当我们揭开第一重的迷雾后，发现会有新的迷雾、新的问题。所以，对待问题抽丝剥茧很关键，而且对于编程也是注重逻辑性，每一行代码都有其作用，需要理清由上而下的逻辑顺序。

        最后就是，对于问题的准确表述，因为互联网上有着很多资料可以学习参考，准确地表述自己的问题，可以帮助我们更快地找到前辈留下的经验。