Maven学习笔记

最新推荐文章于 2023-12-08 22:35:37 发布

llwszjj

最新推荐文章于 2023-12-08 22:35:37 发布

阅读量536

点赞数

CC 4.0 BY-SA版权

分类专栏： Web Java

本文链接：https://blog.csdn.net/llwszjj/article/details/36423639

Java 同时被 2 个专栏收录

30 篇文章

订阅专栏

Web

21 篇文章

订阅专栏

本文深入讲解Maven的核心概念，包括pom.xml配置、依赖管理、命令行操作等，并介绍了依赖范围、传递性和排除方法，以及如何配置本地和远程仓库。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

由于一些项目中，用到了相关知识，所以专门学习了下Maven，与Ant相比，Maven更好地用于不同project之间的依赖。

Maven配置神马的就不讲了，网上到处是。

Maven中最重要的莫过于一个pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.konghao.user</groupId>
  <artifactId>user-service</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>user-service</name>
  <url>http://maven.apache.org</url>

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

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
    	<groupId>org.konghao.user</groupId>
    	<artifactId>user-dao</artifactId>
    	<version>0.0.1-SNAPSHOT</version>
    </dependency>
    <dependency>
    	<groupId>org.konghao.user</groupId>
    	<artifactId>user-log</artifactId>
    	<version>0.0.1-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

解析：
groupId定义了项目属于哪个组，这个组往往和项目所在的组织或公司存在关联。
artifactId定义了当前Maven项目在组中唯一的ID。
version指定了版本。SNAPSHOT指快照，说明该项目还处于开发中，是不稳定的版本。
主要的几个命令

mvn clean compile
mvn clean test/package/install/build

依赖

依赖范围
compile：编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。典型的例子是spring-core，在编译、测试和运行的时候都需要使用该依赖。
test：测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子是JUnit，它只有在编译测试代码及运行测试的时候才需要。
provided：已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。
runtime：运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。
system：系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量，如：
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
import（Maven2.0.9及以上）：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。

依赖范围与classpath的关系

依赖范围（Scope）	对于编译 classpath有效	对于测试classpath有效	对于运行时有效	例子
compile	Y	Y	Y	spring-core
test	—	Y	—	JUnit
provided	Y	Y	—	servlet-api
runtime	—	Y	Y	JDBC驱动实现
system	Y	Y	—	本地的，Maven仓库之外的类文件

传递性依赖
何为传递性依赖

account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-mail的compile范围依赖，commons-logging是account-mail的一个传递性依赖。如下图所示：

传递性依赖和依赖范围

	compile	test	provided	runtime
compile	compile	—	—	runtime
test	test	—	—	test
provided	provided	—	provided	provided
runtime	runtime	—	—	runtime

依赖调解
例如，项目A有这样的依赖关系：A->B->C->X(1.0)、A->D->X(2.0)，X是A的传递性依赖，但是两条依赖路径上有两个版本的X，那么哪个X会被Maven解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。Maven依赖调解的第一原则是：路径最近者优先。该例中X(1.0)的路径长度为3，而X(2.0)的路径长度为2，因此X(2.0)会被解析使用。
依赖调解第一原则不能解决所有问题，比如这样的依赖关系：A->B->Y(1.0)、A->C->Y(2.0)，Y(1.0)和Y(2.0)的依赖路径长度是一样的，都为2。那么到底谁会被解析使用呢？在Maven2.0.8及之前的版本中，这是不确定的。但是从Maven2.0.9开始，为了尽可能避免构不确定性，Maven定义了依赖调解的第二原则；第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那个依赖优胜。该例中，如果B的依赖声明在C之前，那么Y(1.0)就会被解析使用。

可选依赖

最佳实践
排除依赖

<project>
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.wangsy.mvn</groupId>
        <artifactId>project-a</artifactId>
        <version>1.0.0</version>
        <dependencies>
            <dependency>
                <groupId>com.wangsy.mvn</groupId>
                <artifactId> project-b</artifactId>
                <version>1.0.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>com.wangsy.mvn</groupId>
                        <artifactId> project-c</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            <dependency>
                <groupId>com.wangsy.mvn</groupId>
                <artifactId> project-c</artifactId>
                <version>1.1.0</version>
            </dependency>
        <dependencies>
    </project>

上述代码中，项目A依赖于项目B，但是由于一些原因，不想引入传递性依赖C，而是自己显式地声明对于项目C1.1.0版本的依赖。代码中使用exclusions元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusion的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。

归类依赖

项目中有很多关于Spring Framework的依赖，它们分别是org.springframework：spring-core:2.5.6、org.springframework：spring-beans: 2.5.6、org.springframework：spring-context:2.5.6和org.springframework:spring-context-support:2.5.6，它们是来自同一项目的不同模块。因此，所有这些依赖的版本都是相同的，而且可以预见，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。

<project>
        <modelVersion>4.0.0</modelVersion>
        <groupId>com.wangsy.account</groupId>
        <artifactId>account-email</artifactId>
        <name>Account Email</name>
        <version>1.0.0-SNAPSHOT</version>
        
        <properties>
            <springframework.version>2.5.6</springframework.version>
        </properties>
        
        <dependencies>
            <dependency>
                <groupId>org.springframework </groupId>
                <artifactId>spring-core</artifactId>
                <version>${springframework.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework </groupId>
                <artifactId>spring-beans</artifactId>
                <version>${springframework.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework </groupId>
                <artifactId>spring-context</artifactId>
                <version>${springframework.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework </groupId>
                <artifactId>spring-context-support</artifactId>
                <version>${springframework.version}</version>
            </dependency>
        </dependencies>
    </project>

使用常量不仅让代码变得更加简洁，更重要的是可以避免重复，在需要更改的时候，只需要修改一处，降低了错误发生的概率。

仓库

仓库的分类

    本地仓库
    用户目录/.m2/repository是本地仓库目录。、
    编辑~/.m2/settings.xml，设置本地仓库地址。
    <settings>
       <localRepository>d:\java\repository\</localRepository>
    <settings>
    默认情况下，~/.m2/settings.xml文件是不存在的，用户需要从$M2_HOME/conf/settings.xml复制。

    远程仓库
    本地仓库就好比书房，我需要读书的时候先从书房找，相应地，Maven需要构件的时候先从本地仓库找。远程仓库就好比书店（包括实体书店、网上书店等），当我无法从自己的书房找到需要的书的时候，就会从书店购买后放到书房里。当Maven无法从本地仓库找到需要的构件的时候，就会从远程仓库下载构件至本地仓库。一般地，对于每个人来说，书房只有一个，但外面的书店有很多，类似地，对于Maven来说，每个用户只有一个本地仓库，但可以配置访问很多远程仓库。
    中央仓库
    中央仓库是一个默认的远程仓库，Maven的安装文件自带了中央仓库的配置。打开$M2_HOME/lib/maven-model-builder-3.0.jar，然后访问路径
org/apache/maven/model/pom-4.0.0.xml，可以看到如下的配置：

 <repositories>
        <repository>
           <id>central</id>
            <name>MavenRepository Switchboard</name>
           <url>http://repo1.maven.org/maven2</url>
           <layout>default</layout>
            <snapshots>
               <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>

私服
私服的作用：

· 节省自己的外网带宽。

· 加速Maven构建。

· 部署第三方构件。

· 提高稳定性，增强控制。

· 降低中央仓库的负荷。

远程仓库的配置
配置POM使用JBoss Maven仓库

    <project>
        …
        <repositories>
            <repository>
               <id>jboss</id>
               <name>JBoss Repository</name>
               <url>http://repository.jboss.com/maven2/</url>
               <releases>
                   <enabled>true</enabled>
               </releases>
               <snapshots>
                   <enabled>false</enabled>
               <snapshots>
            </repository>
        <repositories>
    </project>

对于releases和snapshots来说，除了enabled，它们还包含另外两个子元素updatePolicy和checksumPolicy：

<snapshots>
        <enabled>true</enabled>
       <updatePolicy>daily</updatePolicy>
       <checksumPolicy>ignore</checksumPolicy>
    <snapshots>

    元素updatePolicy用来配置Maven从远程仓库检查更新的频率，默认的值是daily，表示Maven每天检查一次。其他可用的值包括：never—从不检查更新；always—每次构建都检查更新；interval:X—每隔X分钟检查一次更新（X为任意整数）。
    元素checksumPolicy用来配置Maven检查检验和文件的策略。当构件被部署到Maven仓库中时，会同时部署对应的校验和文件。在下载构件的时候，Maven会验证校验和文件，如果校验和验证失败，怎么办：当checksumPolicy的值为默认的warn时，Maven会在执行构件时输出警告信息，其他可用的值包括：fail—Maven遇到校验和错误就让构建失败；ignore—使Maven完全忽略校验和错误。

   镜像
    如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。换句话说，任何一个可以从仓库Y获得的构件，都能够从它的镜像中获取。举个例子，http://maven.net.cn/content/groups/public/是中央仓库http://repo1.maven.org/maven2/在中国的镜像，由于地理位置的因素，该镜像往往能够提供比中央仓库更快的服务。因此，可以配置Maven使用该镜像来替代中央仓库。编辑settings.xml：

    <settings>
        …
        <mirrors>
            <mirror>
               <id>maven.net.cn</id>
               <name>one of the central mirrors in China</name>
               <url>http://maven.net.cn/content/groups/public/</url>
               <mirrorOf>central<mirrorOf>           
           <mirror>
        <mirrors>
        …
    <settings>

配置私服作为镜像：

 <settings>
        …
        <mirrors>
            <mirror>
               <id>internal-repository</id>
               <name>Internal Repository Manager </name>
               <url>http://192.168.1.100/maven2/</url>
               <mirrorOf>central<mirrorOf>           
           <mirror>
        <mirrors>
        …
    <settings>