(八)maven聚合,继承,properties,import

目录

聚合

继承

版本号的集中约束 properties

基于import pom强制约束依赖方的版本号

聚合

• maven聚合功能，是可以将各个模块，聚合成一个大的模块，给它一个父工程，父模块，父模块里面配置聚合了那些子模块
• 只要对父模块运行一次构建命令，此时maven会自动对这个父模块下面的所有子模块都运行相应的构建命令
• 这样就可以保证一键自动化构建所有的模块，不要一个一个依次去构建。

如果要一次性构建多个模块的工程，那么就需要创建一个父工程，我们可以创建一个parent工程，在其pom.xml中加入以下内容：

<groupId>com.bema.platform</groupId>

<artifactId>payment-platform</artifactId>

<version>1.0.0-SNAPSHOT</version>

<packaging>pom</packaging>

<modules>

    <module>payment-api</module>

    <module>payment-common</module>

    <module>payment-config</module>

    <module>payment-web</module>

    <module>payment-task</module>

</modules>

注意:

• 一般来说会将模块统一放在父工程的目录下，这样就可以用上述形式，否则如果多个工程平级，则要用类似于../payment-api的相对路径。

接着对payment-platform运行mvn clean install，此时就会对payment-platform中所有的工程都进行统一的构建

继承

• maven继承，类似于java继承
• 如果直接将所有的依赖放入父工程，然后子工程用<parent>元素声明继承，然后此时会强制性继承父工程中所有的依赖和插件。

但是实际的场景下，不同的工程需要的依赖是不一样的，可能有的工程需要从父工程继承20个依赖和3个插件；

有的工程需要从父工程继承10个依赖和2个插件。如果按照上面那种最low最普通的做法，会导致每个子工程都强制性从父工程继承所有的依赖。

这样的话，本来某个子工程只要10个依赖，现在导致每次打包，assembly的大包，可能导致每个工程的jar包打包速度变慢，打完以后的包比较大。这种做法是很不好，不推荐。

推荐的一个做法，是在父工程中，使用<depdendencyManagement>和<pluginManagement>两个元素，来声明要被子工程继承的依赖和插件

如果子工程用<parent>元素声明继承父工程，此时不会强制性继承所有的依赖和插件，子工程需要同时声明，自己要继承哪些依赖和插件

但是只要声明groupId和artifactId即可，不需要声明version版本号，因为version全部放在父工程中统一声明，强制约束所有子工程的相同依赖的版本要一样。

• 使用方式 , 将payment-common、payment-web、payment-config工程的pom.xml中加入以下配置

<parent>

<groupId>com.bema.platform</groupId>

<artifactId>payment-platform</artifactId>

<version>1.0.0-SNAPSHOT</version>

</parent>

• 然后将所有工程相同的依赖和插件的配置，全部放入父工程中，此时子工程就会继承父工程的依赖和插件，不需要每个工程都重复定义，而且可以在父工程中统一约束所有依赖和插件的版本。
• 但是这里有个问题，如果直接将所有依赖和插件直接放入父工程，会导致子工程强制性继承，也许子工程并不需要某些依赖呢？
• 此时最好的做法，就是在父工程中，使用<dependencyManagement>元素和<pluginManagement>元素，来声明所有的依赖和插件。
• 此时在子工程中，就可以对自己需要的依赖进行声明，但是不用定义版本号，只要groupId和artifactId即可。这样声明之后才会继承依赖，而且版本由父工程约束。

注意:

• 如果在父工程中，直接用dependencies和plugins来声明依赖和插件，子工程会强制全部继承；
• 如果用dependencyManagemnent和pluginManagement来声明依赖和插件，默认情况下，子工程什么都不继承，只有当子工程声明了某个依赖或者插件的groupId+artifactId，但是不指定版本时，才会从父工程继承那个依赖。在规范的工程管理中，肯定都是用dependencyManagement和pluginManagemnent的。

版本号的集中约束 properties

比如引入spring，或者spring boot，或者spring cloud的多个包，一般就可以统一用properties定义一个版本号，然后下面的依赖全部引用

如果说，我们默认就保留这种情况，有两个问题

（1）比如你的公司要统一升级一下spring版本号

（2）这个时候，可能就需要在一个parent的pom.xml里面，一个一个的修改，很麻烦

（3）可能你还会漏掉某个依赖的版本修改和升级，这就会导致都是spring的项目，结果。不同的子工程的版本不一致，可能在整合使用的时候就会有问题

所以针对这种情况，一般都会在properties元素里面，统一定义一个版本号，然后在这个类似spring的依赖里面，全部用${}占位符来引用一个版本号，那么每次修改，升级spring版本，就直接修改properties元素中的一个地方就可以了，不会出错

 <properties>

<maven.compiler.target>1.8</maven.compiler.target>

<maven.compiler.source>1.8</maven.compiler.source>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

</properties>

<dependency>

<groupId>com.bema.platform</groupId>

<artifactId>payment-channel</artifactId>

<version>${project.version}</version>

</dependency>

基于import pom强制约束依赖方的版本号

在企业工作中，有这样的一种场景

比如说，你开发了一个第三方的一个组件，不属于任何一个项目的基础的一个组件，比如基于activiti开发了一个流程审批的封装以后的一个组件

然后,其他人如果要用你的这个组件，肯定是在depedencies里面去定义和声明，然后看去依赖你的组件，然后才可以基于你的组件去开发么

但是,有一个问题，假设使用的人依赖了你的组件，然后,你的组件依赖了activiti 1.3版本，但是有个问题，结果依赖方自己没头没脑的又声明了一个队activiti 1.2的依赖

此时根据依赖调解的原则，肯定是用他自己的旧版本

比较容易出现依赖的冲突

• 所以说，对于公司里一些重量级的组件，一般来说会采取下面的这种方式

（1）如果你是公司基础组件的开发人，你的组件依赖了很多重要的第三方的开源框架，然后你为了保证依赖你的组件的人，不会自行导入一些开源框架的过旧的版本，导致跟你的组件出现依赖冲突

（2）你需要为你的组件开发一个类型为pom的工程，后缀名为bom，这个工程，要声明一套dependencyManagement，里面声明好对你的组件的依赖的版本号，还有你的组件使用的重要的第三方开源框架的版本号

（3）然后依赖方在引用你的组件的时候，需要在自己的dependencyManagement中，加一个scope范围为import，类型为pom的这么依赖导入，此时就可以将你的bom包声明的那一套依赖的版本号导入他那里，作为版本的约束

（4）然后依赖方接着在dependencies里面可以声明对你的组件的依赖，此时版本号都不用写，因为已经被你约束了

（5）同时，假设依赖方要自己依赖一个过旧的开源框架的版本，会有提示报警，不让他自行定义过旧版本的框架

• demo

 <dependencyManagement>

       <dependencies>

           <dependency>

               <groupId>com.bema.commons</groupId>

               <artifactId>commons-flow-bom</artifactId>

               <version>1.2.9</version>

               <type>pom</type>

               <scope>import</scope>

           </dependency>

       </dependencies>

   </dependencyManagement>