maven基础

pom.xml 解读

  
  <groupId>com.test.mavengroupId>
  <artifactId>pro01-maven-javaartifactId>
  <version>1.0-SNAPSHOTversion>
  
  
  
  
  
  <packaging>jarpackaging>

  <name>pro01-maven-javaname>
  <url>http://maven.apache.orgurl>

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

  
  <dependencies>
  
    <dependency>
  
    
      <groupId>junitgroupId>
      <artifactId>junitartifactId>
      <version>4.12version>
    
    
      <scope>testscope>
    dependency>
  dependencies>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

POM 理念集中体现在 Maven 工程根目录下 pom.xml 这个配置文件中。所以这个 pom.xml 配置文件就是 Maven 工程的核心配置文件。其实学习 Maven 就是学这个文件怎么配置，各个配置有什么用

基本命令

注意：运行 Maven 中和构建操作相关的命令时，必须进入到 pom.xml 所在的目录。

# 1. 删除 target 目录
mvn clean 

# 2.编译
# 主体程序编译结果存放的目录：target/classes
# 测试程序编译结果存放的目录：target/test-classes
# 主程序编译
mvn compile
# 测试程序编译：
mvn test-compile

# 3. 测试操作
# 测试的报告存放的目录：target/surefire-reports
mvn test

# 4. 打包操作
# 打包的结果——jar 包，存放的目录：target
mvn package

# 5. 安装操作
# 安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。
# 安装的效果是将本地构建过程中生成的 jar 包存入 Maven 本地仓库。这个 jar 包在 Maven 仓库中的路径是根据它的坐标生成的。
mvn install


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

工程依赖其他工程

比如说pro2 工程需要依赖 pro1
在 pro02工程的 pom.xml 中，找到 dependencies 标签，在 dependencies 标签中做如下配置：

<dependency>
  <groupId>com.test.mavengroupId>
  <artifactId>pro01-maven-javaartifactId>
  <version>1.0-SNAPSHOTversion>
dependency>
1
2
3
4
5
6
7

依赖的范围

这个scope 是设置依赖的范围
①compile 和 test 对比

②compile 和 provided 对比

③结论

compile：通常使用的第三方框架的 jar 包这样在项目实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。比如 SSM 框架所需jar包。

test：测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。

provided：在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。比如 servlet-api、jsp-api。而这个范围的 jar 包之所以不参与部署、不放进 war 包，就是避免和服务器上已有的同类 jar 包产生冲突，同时减轻服务器的负担。说白了就是：“服务器上已经有了，你就别带啦！”

依赖的传递性

A 依赖 B，B 依赖 C，那么在 A 没有配置对 C 的依赖的情况下，A 里面能不能直接使用 C？

在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 时使用的依赖范围。

• B 依赖 C 时使用 compile 范围：可以传递
• B 依赖 C 时使用 test 或 provided 范围：不能传递，所以需要这样的 jar 包时，就必须在需要的地方明确配置依赖才可以。

冲突依赖的排除

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，A 不想要 C，需要在 A 里面把 C 排除掉。而往往这种情况都是为了避免 jar 包之间的冲突。

利用exclusions 排除冲突的依赖。

<dependency>
  <groupId>com.test.mavengroupId>
  <artifactId>pro01-maven-javaartifactId>
  <version>1.0-SNAPSHOTversion>
  <scope>compilescope>
  
  <exclusions>
    
    <exclusion>
      
      <groupId>commons-logginggroupId>
      <artifactId>commons-loggingartifactId>
    exclusion>
  exclusions>
dependency>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

继承

Maven工程之间，A 工程继承 B 工程

• B 工程：父工程
• A 工程：子工程

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置。

注意：创建父工程打包方式是pom

  <groupId>com.A.mavengroupId>
  <artifactId>A-maven-parentartifactId>
  <version>1.0-SNAPSHOTversion>

  
  <packaging>pompackaging>
1
2
3
4
5
6

创建模块工程
下面 modules 和 module 标签是聚合功能的配置

<modules>  
  <module>B-maven-modulemodule>
modules>
1
2
3

子工程的pom.xml

<parent>
  
  <groupId>com.A.mavengroupId>
  <artifactId>A-maven-parentartifactId>
  <version>1.0-SNAPSHOTversion>
parent>




<artifactId>B-maven-moduleartifactId>

1
2
3
4
5
6
7
8
9
10
11
12
13

父工程中配置依赖的统一管理

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframeworkgroupId>
      <artifactId>spring-coreartifactId>
      <version>4.0.0.RELEASEversion>
    dependency>
    <dependency>
      <groupId>org.springframeworkgroupId>
      <artifactId>spring-beansartifactId>
      <version>4.0.0.RELEASEversion>
    dependency>
    <dependency>
      <groupId>org.springframeworkgroupId>
      <artifactId>spring-contextartifactId>
      <version>4.0.0.RELEASEversion>
    dependency>
    <dependency>
      <groupId>org.springframeworkgroupId>
      <artifactId>spring-expressionartifactId>
      <version>4.0.0.RELEASEversion>
    dependency>
    <dependency>
      <groupId>org.springframeworkgroupId>
      <artifactId>spring-aopartifactId>
      <version>4.0.0.RELEASEversion>
    dependency>
  dependencies>
dependencyManagement>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

有了这些依赖，后面的子工程就不需要写版本号了。

自定属性

<properties>
  <project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
  
  
  <spring.version>4.3.6.RELEASEspring.version>
properties>
1
2
3
4
5
6

在需要的地方使用${}的形式来引用自定义的属性名：

<dependency>
        <groupId>org.springframeworkgroupId>
        <artifactId>spring-coreartifactId>
        <version>${spring.version}version>
      dependency>
1
2
3
4
5

IDEA 建立maven 项目

开启这个自动导入，因为 Project、Module 新创建或 pom.xml 每次修改时都应该让 IDEA 重新加载 Maven 信息。这对 Maven 目录结构认定、Java 源程序编译、依赖 jar 包的导入都有非常关键的影响。

另外也可以通过 IDEA 的 Settings 设置来开启：

配置 Maven 信息

每次创建 Project 后都需要设置 Maven 家目录位置，否则 IDEA 将使用内置的 Maven 核心程序（不稳定）并使用默认的本地仓库位置。这样一来，我们在命令行操作过程中已下载好的 jar 包就白下载了，默认的本地仓库通常在 C 盘，还影响系统运行。

配置之后，IDEA 会根据我们在这里指定的 Maven 家目录自动识别到我们在 settings.xml 配置文件中指定的本地仓库。