Maven学习笔记

来源：互联网发布：windows监控进程流量编辑：程序博客网时间：2024/06/10 03:34

由于一些项目中，用到了相关知识，所以专门学习了下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

spring-core

test

—

JUnit

provided

—

servlet-api

runtime

—

JDBC驱动实现

system

—

本地的，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

—

runtime

test

—

test

provided

—

provided

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>

0 0