Maven 依赖管理
Maven 一个核心的特性就是依赖管理。当我们处理多模块的项目(包含成百上千个模块或者子项目)，模块间的依赖关系就变得非常复杂，管理也变得很困难。针对此种情形，Maven 提供了一种高度控制的方法。
可传递性依赖发现
一种相当常见的情况，比如说 A 依赖于其他库 B。如果，另外一个项目 C 想要使用 A ，那么 C 项目也需要使用库 B。
Maven 可以避免去搜索所有所需库的需求。Maven 通过读取项目文件(pom.xml)，找出它们项目之间的依赖关系。
我们需要做的只是在每个项目的 pom 中定义好直接的依赖关系。其他的事情 Maven 会帮我们搞定。
通过可传递性的依赖，所有被包含的库的图形会快速的增长。当有重复库时，可能出现的情形将会持续上升。Maven 提供一些功能来控制可传递的依赖的程度。
功能
功能描述
依赖调节
决定当多个手动创建的版本同时出现时，哪个依赖版本将会被使用。 如果两个依赖版本在依赖树里的深度是一样的时候，第一个被声明的依赖将会被使用。
依赖管理
直接的指定手动创建的某个版本被使用。例如当一个工程 C 在自己的依赖管理模块包含工程 B，即 B 依赖于 A， 那么 A 即可指定在 B 被引用时所使用的版本。
依赖范围
包含在构建过程每个阶段的依赖。
依赖排除
任何可传递的依赖都可以通过 "exclusion" 元素被排除在外。举例说明，A 依赖 B， B 依赖 C，因此 A 可以标记 C 为 "被排除的"。
依赖可选
任何可传递的依赖可以被标记为可选的，通过使用 "optional" 元素。例如：A 依赖 B， B 依赖 C。因此，B 可以标记 C 为可选的， 这样 A 就可以不再使用 C。
依赖范围
传递依赖发现可以通过使用如下的依赖范围来得到限制：
范围
描述
编译阶段
该范围表明相关依赖是只在项目的类路径下有效。默认取值。
供应阶段
该范围表明相关依赖是由运行时的 JDK 或者 网络服务器提供的。
运行阶段
该范围表明相关依赖在编译阶段不是必须的，但是在执行阶段是必须的。
测试阶段
该范围表明相关依赖只在测试编译阶段和执行阶段。
系统阶段
该范围表明你需要提供一个系统路径。
导入阶段
该范围只在依赖是一个 pom 里定义的依赖时使用。同时，当前项目的POM 文件的 部分定义的依赖关系可以取代某特定的 POM。
依赖管理
通常情况下，在一个共通的项目下，有一系列的项目。在这种情况下，我们可以创建一个公共依赖的 pom 文件，该 pom 包含所有的公共的依赖关系，我们称其为其他子项目 pom 的 pom 父。 接下来的一个例子可以帮助你更好的理解这个概念。
接下来是上面依赖图的详情说明：
App-UI-WAR 依赖于 App-Core-lib 和 App-Data-lib。
Root 是 App-Core-lib 和 App-Data-lib 的父项目。
Root 在它的依赖部分定义了 Lib1、lib2 和 Lib3 作为依赖。
App-UI-WAR 的 pom.xml 文件代码如下：
http://maven.apache.org/xsd/maven-4.0.0.xsd">4.0.0com.companyname.groupnameApp-UI-WAR1.0warcom.companyname.groupnameApp-Core-lib1.0com.companyname.groupnameApp-Data-lib1.0
App-Core-lib 的 pom.xml 文件代码如下：
http://maven.apache.org/xsd/maven-4.0.0.xsd">Rootcom.companyname.groupname1.04.0.0com.companyname.groupnameApp-Core-lib1.0jar
App-Data-lib 的 pom.xml 文件代码如下：
http://maven.apache.org/xsd/maven-4.0.0.xsd">Rootcom.companyname.groupname1.04.0.0com.companyname.groupnameApp-Data-lib1.0jar
Root 的 pom.xml 文件代码如下：
http://maven.apache.org/xsd/maven-4.0.0.xsd">4.0.0com.companyname.groupnameRoot1.0pomcom.companyname.groupname1Lib11.0com.companyname.groupname2Lib22.1com.companyname.groupname3Lib31.1
现在当我们构建 App-UI-WAR 项目时， Maven 将通过遍历依赖关系图找到所有的依赖关系，并且构建该应用程序。
通过上面的例子，我们可以学习到以下关键概念：
公共的依赖可以使用 pom 父的概念被统一放在一起。App-Data-lib 和 App-Core-lib 项目的依赖在 Root 项目里列举了出来(参考 Root 的包类型，它是一个 POM).
没有必要在 App-UI-W 里声明 Lib1, lib2, Lib3 是它的依赖。 Maven 通过使用可传递的依赖机制来实现该细节。

很多时候,我们自己的项目有许多的子模块,之间互相有依赖,但是我们没有私服来发布打好的jar包.
最常见的就是本地有一个Util包, 随手写的其他项目想要引用, 却苦于没有私服. 把代码扔到同一个项目, 强迫症有忍不住.
这个问题Maven是有解决方案的.本质上还是打包发布,只是不再发布到远端的Maven仓库,而是打包完成之后, 将这个jar包安装到本地的maven即可.
首先,在你的util子模块下执行下列命令.
# 打包
mvn clean package
# 安装到本地mvn
mvn install:install-file -Dfile=your_jar_file_path.jar -DgroupId=your_groupId -DartifactId=your_artifactId -Dversion=your_version
# 检查是否安装成功
ll ~/.m2/your_groupId/your_artifactId/

之后, 在需要引入这个jar包的项目的pom.xml文件中,按照正常使用添加即可.
    <dependency>
        <groupId>your_groupId</groupId>
        <artifactId>your_artifactId</artifactId>
        <version>your_version</version>
    </dependency>

当mvn需要引入的时候,会自动从本地仓库去加载的.


完。









联系我
最后，欢迎关注我的个人公众号【 呼延十 】，会不定期更新很多后端工程师的学习笔记。

也欢迎直接公众号私信或者邮箱联系我，一定知无不言，言无不尽。


以上皆为个人所思所得，如有错误欢迎评论区指正。
欢迎转载，烦请署名并保留原文链接。
联系邮箱：huyanshi2580@gmail.com
更多学习笔记见个人博客或关注微信公众号 <呼延十 >------>呼延十

前言
idea构建的maven微服务项目，创建子模块，子模块又创建子模块，新建的模块为maven为灰色，其他子模块也依赖不了


原因
这是由于没有声明项目，忽视子模块导致的导致的
解决
在灰色项目上单击右键unignore projects



点击后

注：还是依赖不了应该检查pom文件

还是比较菜

父项目是A，两个子项目是B和C，B中想引入C，会发现报错了，原因是我们install的顺序有问题

我建议：

先把你添加的其他依赖全部去掉，只剩下单纯的B-A，B-C的依赖，然后先 maven install父项目，把父子关系建立起来，父项目A中要包括duimaven插件的引用，例如：

<build>

        <plugins>

            <plugin>

                <groupId>org.apache.maven.plugins</groupId>

                <artifactId>maven-compiler-plugin</artifactId>

                <version>2.3.2</version>

                <configuration>

                    <source>1.8</source>

                    <target>1.8</target>

                    <encoding>UTF-8</encoding>

                </configuration>

            </plugin>

        </plugins>

    </build>

这样的，之后你再去添加B-C这种子项目间的依赖，应该就没问题了