Maven的pom.xml（坐标的gav、依赖的scope）

什么是pom.xml

　　POM是项目对象模型(Project Object Model)的简称,它是Maven项目中的文件，使用XML表示，名称叫做pom.xml。

作用类似ant的build.xml文件，功能更强大。该文件用于管理：源代码、配置文件、开发者的信息和角色、问题追踪系统、组织信息、项目授权、项目的url、项目的依赖关系等等。事实上，在Maven世界中，project可以什么都没有，甚至没有代码，但是必须包含pom.xml文件。

maven的坐标（GAV）

不论是本地仓库，还是中央仓库，都会存在很多的构件，比如jar和war等等的。

在如此众多的构件中，就是通过groupId,artifactId,version,packaging和classifier来唯一标识一个构件，也就是maven坐标.

groupId：定义当前 Maven 项目所属的实际项目，跟 Java 包名类似，通常与域名反向一一对应。
artifactId：定义当前 Maven 项目的一个模块，默认情况下，Maven 生成的jar，其文件名会以 artifactId 开头
version：定义项目版本。
packaging：定义项目打包方式，如 jar，war，pom，zip ……，默认为 jar。
classifier：定义项目的附属构件， hibernate-core-3.6.6.Final-sources.jar，hibernate-core-3.6.6.Final-javadoc.jar，其中 sources 和 javadoc 就是这两个附属构件的 classifier。classifier 不能直接定义，通常由附加的插件帮助生成.

所有的依赖都是通过坐标来进行管理的（GAV—>groupId,artifactId,version）通过<dependencies>设置依赖

<!--项目构建的时候会选择打包方式（packing），默认为jar-->
<packaging>war</packaging>
<!--引入一个文件的依赖-->
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
<!--scope 主要管理依赖的部署  -->
    <scope>test</scope>
</dependency>

网上的仓库提供了坐标的查询:

　　mvnrepository ：http://mvnrepository.com/ （输入要导入依赖的关键字，复制它的gav）网址记不到？直接百度maven,第一个就是了

　　Maven是如何搜索依赖的？首先会在本地仓库查询，如果本地仓库没有，就去中央仓库查询。

maven的依赖(scope)

　　maven项目构建的过程

依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系，Maven有以下几种依赖范围。

　　1. compile: 编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的maven依赖，对于编译测试运行三种的classpath都有效。

　　2. test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试的classpath有效，在编译主代码或者运行主代码的时候都无法依赖此类依赖。典型的例子是jUnit,它只有在编译测试代码及运行测试代码的时候才有效。

　　3. provided:以提供依赖范围。使用此依赖范围的maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行的时候，由于容器已经提供，就不需要maven重复地引入一遍。打包的时候可以不用包进去，别的设施会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是打包阶段做了exclude操作

　　4. runtime:运行时依赖范围。使用此依赖范围的maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要jdk提供的jdbc的接口，只有在执行测试或者运行测试的时候才需要实现上述接口的jdbc的驱动

　　5. system:系统依赖范围。从参与度来说，和provided相同，不过被依赖项不会从maven仓库下载，而是从本地文件系统拿。需要添加systemPath的属性来定义路径，该依赖与三种范围的classpath

和provided依赖范围完全一致。可能造成不可移植，谨慎使用。

　　6.import:导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。只有在dependencyManagement下才有效果。

测试总结：

默认引入的 jar 包 ------- compile 【默认范围可以不写】（编译、测试、运行都有效）
servlet-api 、jsp-api ------- provided （编译、测试有效，运行时无效防止和 tomcat 下 jar 冲突）
jdbc 驱动 jar 包 ---- runtime （测试、运行有效）
junit ----- test （测试有效）

依赖范围由强到弱的顺序是：compile>provided>runtime>test

如果没有写scope 默认的依赖的范围是：compile

依赖会被传递

　　当我A模块依赖于B模块,而B模块依赖于C模块,那么A模块也就间接的依赖于C模块,

这种依赖主要是基于complie范围(编译范围)的依赖.但是对于scope是test,那不会进行依赖的传递.　

　　有的时候为了避免这种间接的依赖,我们可以使用<exclusions>来排除依赖.

例如：在导入javax.servlet-api 3.0中，在导入jsp-api （附带导入了serclet-api）,可能会出现jar包冲突

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jsp-api</artifactId>
    <version>2.0</version>
    <scope>provided</scope>
    <!-- 排序依赖: servlet-api-2.4依赖 -->
     <exclusions>
        <exclusion>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
        </exclusion>
    </exclusions>
</dependency>

如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准（就近原则）
如果直接依赖中包含有同一个坐标不同版本的资源依赖，以配置顺序下方的版本为准（就近原则)

依赖归类(定义版本变量）

　　通常在项目中，我们会同时依赖同一个构件的不同模块，如 spring-orm-3.2.0，spring-context-3.2.0，且多个模块版本相同，为了维护和升级方便，我们可以对其同一管理，这时可以使用到 Maven 属性，类似于变量的概念。

<properties>//变量名随便定义
      <springframework.version>3.2.0.RELEASE</springframework.version>
  </properties>

  <dependencies>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-orm</artifactId>
          <version>${springframework.version}</version>
     </dependency>
     <dependency>
         <groupId>org.springframework</groupId>
         <artifactId>spring-context</artifactId>
         <version>${springframework.version}</version>
     </dependency>
</dependencies>

posted @ 2020-06-06 15:17 64Byte 阅读(1625) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

64Byte