Maven学习（二）

最新推荐文章于 2025-01-18 00:37:32 发布

Kevin's life

最新推荐文章于 2025-01-18 00:37:32 发布

阅读量271

点赞数 2

分类专栏：【JAVA】文章标签： maven maven继承依赖

本文链接：https://blog.youkuaiyun.com/ght886/article/details/82218919

版权

【JAVA】专栏收录该内容

11 篇文章

订阅专栏

一、maven中的继承，依赖和聚合

1.1、 Maven中的继承

在Maven中，子项目是可以继承父项目中的依赖的，比如说我们有一个父项目maven-parent，该父项目拥有一个子项目A，如果在父项目中依赖了junit，那么在子项目A中即便是没有引入junit，在子项目中仍然能够使用junit，因为子项目天然继承了父项目中的junit依赖。
maven提供了一个父类maven项目(新建工程Parent，目的消除子工程的配置文件中重复的内容，所以无需代码类，删除代码)来装所有公共使用的jar，只要继承都可以使用。
配置步骤：
假设子工程都需要用到了相同的junit版本4.9
(1)在父类工程的pom.xml中配置依赖的jar包
(2)在各个子工程中引入父工程＜parent>，放在＜denpendencies>上面，同时在所有子项目中删除重复的＜groupId>、＜version>、＜dependency>
(3)修改父工程中的pom.xml
把＜packaging>jar＜/packaging> 改为＜packaging>pom＜/packaging>
这是一个父工程，实际是一个聚合工程，它没有实际代码，它的作用是抽象出子工程公用的内容。这个时候就不需要子工程的pom.xml文件配置公共的jar包了。

1.2、Maven中的依赖传递

在Maven中，依赖是可以传递的，就是说假设存在三个项目，分别是项目A，项目B以及项目C，假设C依赖于B，B依赖于A，那么我们可以根据Maven项目依赖的特征不难推出项目C也依赖于A。

1.2.1 maven的几种依赖范围(＜scope>＜/scope>)

名称	有效范围
Compile	编译，测试，运行。默认的依赖范围
Test	测试，如Junit
Runtime	运行，如JDBC
Provided	编译，测试，如ServletAPI
System	编译，侧四，依赖于系统变量

1.2.2选择性依赖

在依赖中用＜optional>可以直接去除这种依赖传递的特性，也就是说，如果别的项目引用设置了此依赖的项目，这个mysql-connector-java不会被依赖到。例如在项目A中配置mysql-connector-java的依赖，如果项目B依赖项目A，那么，此时项目B中不会依赖mysql-connector-java了。

<!-- 排除依赖 --> 

 <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.7.21</version>
      <optional>true<optional> 
 </dependency>

1.2.3 排除依赖

如果第三方的jar包没有用＜optional>去除依赖的传递性，那么我们可以在当前的项目中使用＜exclusion>元素声明排除依赖。例如，项目A中配置了mysql-connector-java的依赖，如果项目B需要引用项目A，但是同时又不需要mysql-connector-java的包，这个时候使用，exclusion>元素排除即可，这种用法可以刻解决包版本冲突的问题。

<!-- 排除依赖 -->

 <dependency>    
        <groupId>mysql</groupId>
         <artifactId>mysql-connector-java</artifactId> 
            <exclusions> 
               <exclusion>
　　　　　　　　　　 <groupId>mysql</groupId>
                  <artifactId>mysql-connector-java</artifactId>
               </exclusion> 
            </exclusions> 
</dependency>

1.3、解决依赖冲突

举个例子，若A和B依赖了一个不同版本的相同的构件，那么对于依赖于A和B的C来说，他究竟依赖的是A和B的哪一个版本的构件。

原则：

1.3.1、短路优先(优先解析路径短的版本)

比如 A->B->C->X(jar)
A->D->X(jar)
则A会优先解析A->D->X(jar）这个X的版本，因为路径短。

1.3.2、先声明先优先(在路径相同的情况下,则谁先声明，先解析谁)

1.4 maven中的聚合关系

我们都知道，在项目中完成某一个模块的功能的时候，它需要几个模块的公共协作才能完成(不是组合关系)。
在继承关系中，子工程要依赖父工程的包，我们从父工程到子工程依次执行每个项目的mvn install命令，打包到本地仓库中去，除了步骤很繁琐其他没问题。能不能简化这些步骤呢？maven的聚合就很好的解决了这个问题。
如果我们想一次构建多个项目模块，那我们就需要对多个项目模块进行聚合，这样做，我们只需要对父工程进行mvn install命令，它就会依次把继承依赖的所有工程都自动执行mvn clean test compile package install命令了。这就是mvn的强大之处。
当然，需要在父工程中配置：

<!--taotao-manager 父类 -->

<modules>
        <module>taotao-manager-pojo</module>
        <module>taotao-manager-dao</module>
        <module>taotao-manager-service</module>
        <module>taotao-manager-interface</module>
        <module>taotao-manager-web</module>
</modules>

这样配置后就无需一个一个的安装 mvn install，只需要父工程的 pom.xml 上 Run As，就会连同全部一起进行安装。

二、dependencies与dependencyManagement的区别

2.1、DepencyManagement应用场景

当我们的项目模块很多的时候，我们使用Maven管理项目非常方便，帮助我们管理构建、文档、报告、依赖、scms、发布、分发的方法。可以方便的编译代码、进行依赖管理、管理二进制库等等。
由于我们的模块很多，所以设计者又抽象出一个parent来管理子项目的公共的依赖。为了项目的正确运行，必须让所有的子项目使用依赖项的统一版本，必须确保应用的各个项目的依赖项和版本一致，才能保证测试的和发布的是相同的结果。
在我们项目顶层的POM文件中，我们会看到dependencyManagement元素。通过这个元素来管理jar包的版本，让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号。

2.1.1实例：（taotaomall项目）

taotao-common 是子类继承了taotao-parent 父类
taotao-parent 父类工程中的代码（pom.xml）

  <!-- taotao-parent 父类-->
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.taotaomall</groupId>
  <artifactId>taotao-parent</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>taotao-parent</name>
  <url>http://maven.apache.org</url>

  <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>
        <!--声明了版本-->
        <junit.version>4.11</junit.version>
        <mybatis.version>3.2.8</mybatis.version>
        ........
  </properties>
  <!-- 集中管理依项，默认子类都可以继承。子类中只需引用一个依赖而不用列出版本号-->
  <dependencyManagement>
  <dependencies>
  <!-- 单元测试 -->
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>${junit.version}</version>
      <scope>test</scope>
    </dependency>
    <!-- Mybatis -->
    <dependency>
      <groupId>org.mybatis</groupId>
      <artifactId>mybatis</artifactId>
      <version>${mybatis.version}</version>
    </dependency>
    ......
    </dependencies>
</dependencyManagement>

taotao-common子类中的代码（pom.xml）

<parent>
    <artifactId>taotao-parent</artifactId>
    <groupId>com.taotaomall</groupId>
    <version>1.0-SNAPSHOT</version>
</parent>

  <modelVersion>4.0.0</modelVersion>
  <artifactId>taotao-common</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
  <name>taotao-common</name>
  <url>http://maven.apache.org</url>

   <!--子类中的依赖项-->
   <dependencies>
    <!-- 这个插件不继承父类，指定了自己的版本 -->
        <dependency>
          <groupId>taglibs</groupId>
          <artifactId>standard</artifactId>
          <version>1.0.4</version>
        </dependency>
        <!-- 这个插件继承于父类，没有指定版本 -->
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <scope>test</scope>
        </dependency>
        ......
   </dependencies>

这样做的好处：统一管理项目的版本号，确保应用的各个项目的依赖和版本一致，才能保证测试的和发布的是相同的成果，因此，在顶层pom中定义共同的依赖关系。同时可以避免在每个使用的子项目中都声明一个版本号，这样想升级或者切换到另一个版本时，只需要在父类容器里更新，不需要任何一个子项目的修改；如果某个子项目需要另外一个版本号时，只需要在自己的dependencies中声明一个版本号即可。子类就会使用子类声明的版本号，不继承于父类版本号。

2.2、Dependencies

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