maven框架

Table of Contents

 

Maven:

01.什么是Maven？

1.1Maven的两个经典作用

1.1.1 Maven的依赖管理

1.1.2 项⽬的⼀键构建

02.Maven的安装

2.1官⽹去下载它的安装软件

2.2Maven的配置

2.3Maven软件版本测试

03.Maven仓库

3.1Maven仓库的分类

3.2Maven本地仓库的配置

04.Maven⼯程的认识

4.1 Maven⼯程的⽬录结构

 

05. Maven常⽤命令

5.1 compile

5.2 test

5.3 clean

5.4 package

5.5 install

5.6 Maven指令的⽣命周期

06.Maven POM

07.Maven 引入外部依赖（坐标）

7.1坐标的来源⽅式

---

Maven:

01.什么是Maven？

Maven是⼀个项⽬管理⼯具，它包含了⼀个项⽬对象模型 (POM：Project Object Model)，⼀组标准集合，⼀个项⽬⽣命周期(Project Lifecycle)，⼀个依赖管 理系统(Dependency Management System)，和⽤来运⾏定义在⽣命周期阶段(phase)中插件(plugin) ⽬标(goal)的逻辑。

1.1Maven的两个经典作用

1.1.1 Maven的依赖管理

Maven的⼀个核⼼特性就是依赖管理。当我们涉及到多模块的项⽬（包含成百个模块或者⼦项⽬），管 理依赖就变成⼀项困难的任务。Maven展示出了它对处理这种情形的⾼度控制。

传统的WEB项⽬中，我们必须将⼯程所依赖的jar包复制到⼯程中，导致了⼯程的变得很⼤ 那么maven⼯程是如何使得⼯程变得很少呢？

1.1.2 项⽬的⼀键构建

我们的项⽬，往往都要经历编译、测试、运⾏、打包、安装 ，部署等⼀系列过程。 什么是构建？ 指的是项⽬从编译、测试、运⾏、打包、安装 ，部署整个过程都交给maven进⾏管理，这个过程称为 构建。

⼀键构建指的是整个构建过程，使⽤maven⼀个命令可以轻松完成整个⼯作

02.Maven的安装

2.1官⽹去下载它的安装软件

⾸先要到官⽹去下载它的安装软件。 下载地址： http://maven.apache.org/download.cgi

Maven下载后，将Maven解压到⼀个没有中⽂没有空格的路径下，⽐如D:\software\maven下⾯。

bin:存放了maven的命令，⽐如我们前⾯⽤到的mvn test

boot:存放了⼀些maven本身的引导程序，如类加载器等

conf:存放了maven的⼀些配置⽂件，如setting.xml⽂件

lib:存放了maven本身运⾏所需的⼀些jar包

⾄此我们的maven软件就可以使⽤了，前提是你的电脑上之前已经安装并配置好了JDK。

2.2Maven的配置

新建环境变量MAVEN_HOME ，变量值就是你的maven安装的路径

将Maven 的bin⽬录加⼊到Path中

2.3Maven软件版本测试

win+R打开命令行界面，输入mvn -v命令检查 maven是否安装成功，看到maven的版本即安装成功

03.Maven仓库

3.1Maven仓库的分类

maven的⼯作需要从仓库下载⼀些jar包，如下图所示，本地的项⽬A、项⽬B等都会通过maven软件从远程仓库（可以理解为互联⽹上的仓库）下载jar包并存在本地仓库，本地仓库就是本地⽂件夹，当第⼆次需要此jar包时则不再从远程仓库下载，因为本地仓库已经存在了，可以将本地仓库理解为缓存，有了本地仓库就不⽤每次从远程仓库下载了。

● 本地仓库 ：⽤来存储从远程仓库或中央仓库下载的插件和jar包，项⽬使⽤⼀些插件或jar包，优先从本地仓库查找

默认本地仓库位置在user.dir/.m2/repository ， {user.dir}表示windows⽤户⽬录。

●远程仓库：如果本地需要插件或者jar包，本地仓库没有，默认去远程仓库下载。 远程仓库可以在互联⽹内也可以在局域⽹内。

●中央仓库：在maven软件中内置⼀个远程仓库地址http://repo1.maven.org/maven2 ，它是中央仓库，服务于整个互联⽹，它是由Maven团队⾃⼰维护，⾥⾯存储了⾮常全的jar包，它包含了世界上⼤部分流⾏的开源项⽬构件。

 

3.2Maven本地仓库的配置

打开Maven⽬录下conf/setting.xml⽂件配置

<!-- 配置本地仓库路径 -->
 <localRepository>D:/Repository</localRepository>

由于默认的中央仓库速度⽐较慢，建议更换为阿⾥的仓库

 <mirror>
 <id>alimaven</id>
 <mirrorOf>central</mirrorOf>
 <name>aliyun maven</name>
 <url>https://maven.aliyun.com/repository/central</url>
 </mirror>

04.Maven⼯程的认识

4.1 Maven⼯程的⽬录结构

作为⼀个maven⼯程，它的src⽬录和pom.xml是必备的。

普通java项⽬

进⼊src⽬录后，我们发现它⾥⾯的⽬录结构如下：

src/main/java —— 存放项⽬的.java⽂件

src/main/resources —— 存放项⽬资源⽂件，如spring, hibernate配置⽂件

src/test/java —— 存放所有单元测试.java⽂件，如JUnit测试类

src/test/resources —— 测试资源⽂件

target —— 项⽬输出位置，编译后的class⽂件会输出到此⽬录

pom.xml——maven项⽬核⼼配置⽂件

注意：如果是普通的java项⽬，那么就没有webapp⽬录。

 

05. Maven常⽤命令

我们可以在cmd中通过⼀系列的maven命令来对我们的maven-helloworld⼯程进⾏编译、测试、运 ⾏、打包、安装、部署。

5.1 compile

compile是maven⼯程的编译命令，作⽤是将src/main/java下的⽂件编译为class⽂件输出到target⽬录下。

5.2 test

test是maven⼯程的测试命令 mvn test，会执⾏src/test/java下的单元测试类。 cmd执⾏mvn test执⾏src/test/java下单元测试类

5.3 clean

clean是maven⼯程的清理命令，执⾏ clean会删除target⽬录及内容。

5.4 package

package是maven⼯程的打包命令，对于java⼯程执⾏package打成jar包，对于web⼯程打成war包。

5.5 install

install是maven⼯程的安装命令，执⾏install将maven打成jar包或war包发布到本地仓库。

当后⾯的命令执⾏时，前⾯的操作过程也都会⾃动执⾏

 

5.6 Maven指令的⽣命周期

一个典型的 Maven 构建（build）生命周期是由以下几个阶段的序列组成的：

Maven 有以下三个标准的生命周期：

maven对项⽬构建过程分为三套相互独⽴的⽣命周期，请注意这⾥说的是“三套”，⽽且“相互独⽴”，这 三套⽣命周期分别是：

Clean Lifecycle 在进⾏真正的构建之前进⾏⼀些清理⼯作。

Default Lifecycle 构建的核⼼部分，编译，测试，打包，部署等等。

Site Lifecycle ⽣成项⽬报告，站点，发布站点。

 

06.Maven POM

POM( Project Object Model，项目对象模型 ) 是 Maven 工程的基本工作单元，是一个XML文件，包含了项目的基本信息，用于描述项目如何构建，声明项目依赖，等等。

执行任务或目标时，Maven 会在当前目录中查找 POM。它读取 POM，获取所需的配置信息，然后执行目标。

POM 中可以指定以下配置：

• 项目依赖
• 插件
• 执行目标
• 项目构建 profile
• 项目版本
• 项目开发者列表
• 相关邮件列表信息

在创建 POM 之前，我们首先需要描述项目组 (groupId), 项目的唯一ID。

<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>
    <!-- 公司或者组织的唯一标志，并且配置时生成的路径也是由此生成， 如com.companyname.project-group，maven会将该项目打成的jar包放本地路径：/com/companyname/project-group -->
    <groupId>com.companyname.project-group</groupId>
 
    <!-- 项目的唯一ID，一个groupId下面可能多个项目，就是靠artifactId来区分的 -->
    <artifactId>project</artifactId>
 
    <!-- 版本号 -->
    <version>1.0</version>
</project>

所有 POM 文件都需要 project 元素和三个必需字段：groupId，artifactId，version。

07.Maven 引入外部依赖（坐标）

如果我们需要引入第三库文件到项目，该怎么操作呢？

pom.xml 的 dependencies 列表列出了我们的项目需要构建的所有外部依赖项。

<dependencies>
    <!-- 在这里添加你的依赖 -->
    <dependency>
        <groupId>ldapjdk</groupId>  <!-- 库名称，也可以自定义 -->
        <artifactId>ldapjdk</artifactId>    <!--库名称，也可以自定义-->
        <version>1.0</version> <!--版本号-->
        <scope>system</scope> <!--作用域-->
        <systemPath>${basedir}\src\lib\ldapjdk.jar</systemPath> <!--项目根目录下的lib文件夹下-->
    </dependency> 
</dependencies>

7.1坐标的来源⽅式

添加依赖需要指定依赖jar包的坐标，但是很多情况我们是不知道jar包的的坐标，可以通过如下⽅式查询：

 

 

 pom.xml文件：

7.2依赖范围scope

<dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <version>4.12</version>
     <scope>compile</scope>
</dependency>

dependency中有一个scope标签，表示添加坐标时需要指定依赖范围，依赖范围包括：

• compile：编译范围，指A在编译时依赖B，此范围为默认依赖范围。编译范围的依赖会⽤在编译、 测试、运⾏，由于运⾏时需要所以编译范围的依赖会被打包。
• provided：provided依赖只有在当JDK或者⼀个容器已提供该依赖之后才使⽤， provided依赖在 编译和测试时需要，在运⾏时不需要，⽐如：servlet api被tomcat容器提供。 
• runtime：runtime依赖在运⾏和测试系统的时候需要，但在编译的时候不需要。⽐如：jdbc的驱 动包。由于运⾏时需要所以runtime范围的依赖会被打包。
• test：test范围依赖 在编译和运⾏时都不需要，它们只有在测试编译和测试运⾏阶段可⽤，⽐如： junit。由于运⾏时不需要所以test范围依赖不会被打包。
• system：system范围依赖与provided类似，但是你必须显式的提供⼀个对于本地系统中JAR⽂件 的路径，需要指定systemPath磁盘路径，system依赖不推荐使⽤。

测试总结：

默认引⼊ 的jar包 ------- compile 【默认范围 可以不写】（编译、测试、运⾏ 都有效 ）

servlet-api 、jsp-api ------- provided （编译、测试 有效， 运⾏时⽆效 防⽌和tomcat下jar冲突）

jdbc驱动jar包 ---- runtime （测试、运⾏ 有效 ）

junit ----- test （测试有效）

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