maven项目继承依赖中包版本的说明

                                                 继承

参考博客MAVEN的继承详解_parent中哪些标签可以被子项目继承_32224047_yw的博客-CSDN博客

https://blog.csdn.net/liupeifeng3514/article/details/80236827 

dependencies 和dependencyManagement

在Maven多模块的时候，管理依赖关系是非常重要的，各种依赖包冲突，查询问题起来非常复杂，于是就用到了，

示例说明，

在父模块中：

       
           
                mysql
                mysql-connector-java
                5.1.44
           
           
       

那么在子模块中只需要和即可，如：
 
       
            mysql
            mysql-connector-java
       
 

说明：
使用dependencyManagement可以统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，不用每个模块项目都弄一个版本号，不利于管理，当需要变更版本号的时候只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个特殊的版本号时，只需要在自己的模块dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。

与dependencies区别：

1)Dependencies相对于dependencyManagement，所有生命在dependencies里的依赖都会自动引入，并默认被所有的子项目继承。
2)dependencyManagement里只是声明依赖，并不自动实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。

也就是说如果我们在父类中直接 

       
            mysql
            mysql-connector-java
       
 

 那么父类中注入了这个bean并且继承这个父类的子类也会继承这个bean也就是说子类中也有了这个bean。

plugins 和 pluginManagement 的区别

plugins 和 pluginManagement 的区别，和我们前面研究过的 dependencies 和 dependencyManagement 的区别是非常类似的。plugins 下的 plugin 是真实使用的，而 pluginManagement 下的 plugins 下的 plugin 则仅仅是一种声明，子项目中可以对 pluginManagement 下的 plugin 进行信息的选择、继承、覆盖等。

pluginManagement使用实战
假如存在两个项目，项目A为项目B的父项目，其关系通过pom文件的关系确定。项目A的父pom文件片段如下：

   
       
            org.apache.maven.plugins
            maven-source-plugin
            2.1
           
                true
           
           
               
                    compile
                   
                        jar
                   
               
           
       
   


如果项目B也想使用该plugin配置，则在项目B的子pom文件中只需要如下配置：

   
        org.apache.maven.plugins
        maven-source-plugin
   

我们可以看到，子pom文件中，省去了版本、配置细节等信息，只需要指定groupId和artifactId，其他信息均从父pom文件继承。当然，如果子pom文件想定制自己的特定内容，可以另行设置，并会覆盖从父pom文件继承到的内容。

需要注意的是，dependencies 和 dependencyManagement 均是 project 下的直接子元素，但是 plugins 和 pluginManagement 却是 project 下 build 的直接子元素

拓展

下面是子项目可以从父项目中继承的东西

那么父pom文件中哪些元素可以被继承呢？

groupId：项目组ID，项目坐标的核心元素
version：项目版本，项目坐标的核心元素
description：项目的描述信息
organization：项目的组织信息
properties：自定义的Maven属性
dependencies：项目的依赖配置
repositories：项目的仓库配置
build：包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等
reporting：包括项目的报告输出目录配置、报告插件配置等。
dependencyManagement：项目的依赖管理配置
pluginManagement  插件管理
————————————————
                                                     

                                 依赖一个项目

我们在微服务项目的时候经常会出现一个项目依赖另一个微服务项目的时候，通常就是微服务项目依赖一个·base工程，或者一个content_api工程依赖一个content_service工程。

这时候我们的依赖jar包是怎么一个情况呢？

事实上我们一个项目依赖另一个项目会依赖这个项目中依赖的其他jar包，但是这时候如果我们本项目中有这些jar包，那么服从就近原则。

依赖冲突与解决
   依赖冲突：一个项目A，通过不同依赖传递路径依赖于X，若在不同路径下传递过来的X版本不同，那么A应该导入哪个版本的X包呢？

    冲突解决方案：

    1：如果依赖路径的长度不同，则“短路优先”：
         A—>B—>C—>D—>E—>X(version 0.0.1)
         A—>F—>X(version 0.0.2)
         则A依赖于X(version 0.0.2)。

     2：依赖路径长度相同情况下，则“先声明优先”：
         A—>E—>X(version 0.0.1)
         A—>F—>X(version 0.0.2)
         则在项目A的中，E、F那个在先则A依赖哪条路径的X。
————————————————

从图中可以看出来我们的api项目依赖了service项目，但是对于service中依赖的包我们没有的当然就是依赖这个项目中的包了，但是有的根据就近原则直接依赖我们api中的jar包。

除了依赖的jar包还会依赖什么东西呢。比如我们spring容器中的bean以及我们的配置文件bootstrap.yaml会不会产生依赖呢。（bean不是依赖的而是spring进行扫描的）

SpringBoot应用启动时，默认会自动扫描与启动类在同个包以及子包下的Bean，那么我们依赖的service工程只要我们的文件所在包的位置正确，并且使用了@Srvice类似的注解，那么就会被我们的spring扫描到。

在Spring Boot中，包扫描是由@SpringBootApplication注解所标注的启动类进行扫描的。

@SpringBootApplication是一个复合注解，包含了多个元注解，其中之一是@ComponentScan。@ComponentScan注解指示Spring扫描和注册指定包及其子包中所有的组件（包括带有@Controller、@Service、@Repository和@Configuration等注解的类）到Spring容器中。

当启动Spring Boot应用程序时，它会自动扫描启动类所在包及其子包中的组件，并将这些组件自动注册到Spring容器中。这样，在应用程序中可以通过依赖注入（@Autowired）或者使用其他方式来使用这些被注册的组件。

需要注意的是，Spring Boot默认情况下，会扫描启动类所在包及其子包中的组件。如果启动类不在根包（root package）中，那么需要通过@ComponentScan注解的value属性或basePackages属性来指定要扫描的包。例如：

@SpringBootApplication @ComponentScan(basePackages = "com.example.myapp") public class MyAppApplication { // ... }

上述示例中，指定了要扫描的包为"com.example.myapp"，并会将该包及其子包中的组件注册到Spring容器中。

对于bootstrap中配置文件会不会进行依赖。我想