[01] Maven

1. Maven 安装

检查 JAVA_HOME 环境变量
- Maven 是使用 Java 开发的，所以必须知道当前系统环境中 JDK 的安装目录。
- cmd 窗口输入命令：echo %JAVA_HOME%
解压 Maven 的核心程序到一个非中文无空格的目录下
配置环境变量
查看 Maven 版本信息验证安装是否正确

配置本地仓库

Maven 默认的本地仓库：~\.m2\repository 目录（~ 表示当前用户的家目录）；

Maven 的核心程序并不包含具体功能，仅负责宏观调度。具体功能由插件来完成。Maven 核心程序会到本地仓库中查找插件。如果本地仓库中没有就会从远程中央仓库下载。此时如果不能上网则无法执行 Maven 的具体功能。为了解决这个问题，我们可以将 Maven 的本地仓库指向一个在联网情况下下载好的目录。

<setting ...>
    <localRepository>D:\Maven\MavenRepository</localRepository>

    <mirrors>
        <mirror>
            <id>alimaven</id>
            <mirrorOf>central</mirrorOf>
            <name>aliyun maven</name>
            <url>http://maven.aliyun.com/nexus/content/groups/public</url>
        </mirror>
    </mirrors>

    <profile>
        <id>jdk-1.8</id>
        <activation>
            <activeByDefault>true</activeByDefault>
            <jdk>1.8</jdk>
        </activation>
        <properties>
            <maven.compiler.source>1.8</maven.compiler.source>
            <maven.compiler.target>1.8</maven.compiler.target>
            <maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
        </properties>
    </profile>
</settting>

2. HelloWorld

创建 Maven 的核心配置文件 pom.xml

<?xml version="1.0" ?>
<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>cn.edu.nuist.maven</groupId>
    <artifactId>Hello</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>Hello</name>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.9</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

编写主代码

package cn.edu.nuist.maven;
public class Hello {
    public String sayHello(String name){
        return "Hello "+name+"!";
    }
}

编写测试代码

package cn.edu.nuist.maven;
import org.junit.Test;
import static junit.framework.Assert.*;

public class TestHello {
    @Test
    public void testHello(){
        Hello hello = new Hello();
        String results = hello.sayHello("baishizhu");
        assertEquals("Hello baishizhu!", results); // 断言
    }
}

3. POM&GAV

POM（Project Object Model，项目对象模型）是将 Java 工程的相关信息封装为对象作为便于操作和管理的模型，也是 Maven 工程的核心配置。可以说学习 Maven 就是学习 pom.xml 文件中的配置。

约定的目录结构

现在 JavaEE 开发领域普遍认同一个观点：约定>配置>编码。意思就是能用配置解决的问题就不编码，能基于约定的就不进行配置。而 Maven 正是因为指定了特定文件保存的目录才能够对我们的 Java 工程进行自动化构建。目录结构含义参见 HelloWorld 的描述。

GAV 坐标

几何中的坐标
- 在一个平面中使用 x、y 两个向量可以唯一的确定平面中的一个点。
- 在空间中使用 x、y、z 三个向量可以唯一的确定空间中的一个点。
Maven 中的坐标：使用如下 3 个向量在 Maven 的仓库中唯一的确定一个 Maven 工程
- groupId：公司或组织的域名倒序 + 当前项目名称
- artifactId：当前项目的模块名称
- version：当前模块的版本

通过坐标到仓库中查找 jar 包，将 GAV 的 3 个向量连起来 cn.edu.nuist.maven+HelloWorld+0.0.1-SNAPSHOT，以连起来的字符串作为目录结构到仓库中查找：cn/edu/nuist/HelloWorld/0.0.1-SNAPSHOT/HelloWorld-0.0.1-SNAPSHOT.jar。

注意！我们自己的 Maven 工程必须执行安装操作才会进入仓库（安装命令 mvn install）。

STS 配置 Maven

导入已存在 Maven 项目：

4. 依赖管理

依赖

当 A-jar 包需要用到 B-jar 包中的类时，我们就说 A 对 B 有依赖。例如：commons-fileupload-1.3.jar 依赖于 commons-io-2.0.1.jar。

通过 ↑ Maven 工程我们已经看到，当前工程会到本地仓库中根据坐标查找它所依赖的 jar 包。

配置依赖的基本形式是使用 <dependency> 指定目标 jar 包的坐标。例如：

<dependencies>
    <dependency>
        <!-- GAV 坐标 -->
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.10</version>
        <!-- 依赖的范围 -->
        <scope>test</scope>
    </dependency>
</dependencies>

直接依赖和间接依赖

如果 A 依赖 B，B 依赖 C，那么 A→B 和 B→C 都是“直接依赖”，而 A→C 是“间接依赖”。

依赖的范围

当一个 Maven 工程添加了对某个 jar 包的依赖后，这个被依赖的 jar 包可以对应下面几个可选的范围：

compile [默认]
- main 目录下的 Java 代码可以访问这个范围的依赖
- test 目录下的 Java 代码可以访问这个范围的依赖
- 部署到 Tomcat 服务器上运行时要放在 WEB-INF 的 lib 目录下
- 例如：对 HelloWorld 的依赖。主程序、测试程序和服务器运行时都需要用到
test
- main 目录下的 Java 代码不能访问这个范围的依赖
- test 目录下的 Java 代码可以访问这个范围的依赖
- 部署到 Tomcat 服务器上运行时不会放在 WEB-INF 的 lib 目录下
- 例如：对 junit 的依赖。仅仅是测试程序部分需要
provided
- main 目录下的 Java 代码可以访问这个范围的依赖
- test 目录下的 Java 代码可以访问这个范围的依赖
- 部署到 Tomcat 服务器上运行时不会放在 WEB-INF 的 lib 目录下
- 例如：servlet-api 在服务器上运行时，Servlet 容器会提供相关 API，所以部署的时候不需要
runtime [了解]
- main 目录下的 Java 代码不能访问这个范围的依赖
- test 目录下的 Java 代码可以访问这个范围的依赖
- 部署到 Tomcat 服务器上运行时会放在 WEB-INF 的 lib 目录下
- 例如：JDBC 驱动。只有在测试运行和在服务器运行的时候才决定使用什么样的数据库连接
其他：import、system ...

依赖的传递性

当存在间接依赖的情况时，主工程对间接依赖的 jar 可以访问吗？这要看间接依赖的 jar 包引入时的依赖范围——只有依赖范围为 compile 时可以访问。例如：

依赖的原则

这里“声明”的先后顺序指的是 <dependency> 配置的先后顺序。

依赖的排除

有的时候为了确保程序正确可以将有可能重复的间接依赖排除。示例如下：

假设当前工程 A 依赖于 C，而 C 依赖于 spring-core-4.0.0.RELEASE.jar。故 spring-core-4.0.0.RELEASE.jar 依赖的 commons-logging-1.1.1.jar 对于 A 来说是间接依赖。

若当前工程 A 直接依赖 commons-logging-1.1.2.jar，则可以在 A-pom.xml 中加入 exclusions 以排除版本为 1.1.1 的 commons-logging 的间接依赖。

<dependency>
    <groupId>cn.edu.nuist.maven</groupId>
    <artifactId>C</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <!-- 依赖排除 -->
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<!-- 根据路径最短者优先原则，就算不设置依赖排除，也会用自己配的 -->
<dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1.2</version>
</dependency>

统一管理 jar 版本

以对 Spring 的 jar 包依赖为例：Spring 的每一个版本中都包含 spring-core、spring-context 等 jar 包。我们应该导入版本一致的 Spring jar 包，而不是使用 4.0.0 的 spring-core 的同时使用 4.1.1 的 spring-context。

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.0.0.RELEASE</version>
</dependency>

<!-- ... -->

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>4.0.0.RELEASE</version>
</dependency>

问题是如果我们想要将这些 jar 包的版本统一升级为 4.1.1，是不是要手动一个个修改呢？显然，我们有统一配置的方式：

<!-- 这样一来，进行版本调整的时候只改一改 ↓ 就行了 -->
<properties>
    <spring.version>4.1.1.RELEASE</spring.version>
</properties>

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>${spring.version}</version>
</dependency>

<!-- ... -->

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${spring.version}</version>
</dependency>

5. Maven 仓库

分类：

本地仓库（setting.xml）

<localRepository>D:\Maven\MavenRepository</localRepository>

远程仓库
- 私服：架设在当前局域网环境下，为当前局域网范围内的所有 Maven 工程服务；
- 中央仓库：架设在 Internet 上，为全世界所有 Maven 工程服务；
- 中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。
```
<mirror>
    <id>alimaven</id>
    <mirrorOf>central</mirrorOf>
    <name>aliyun maven</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>
```

仓库中的文件：

Maven 的插件
我们自己开发的项目的模块
第三方框架或工具的 jar 包

※ 不管是什么样的 jar 包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖。

6. Maven 生命周期

Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命令了；
Maven 有 3 套相互独立的生命周期，分别是：
- Clean Lifecycle 在进行真正的构建之前进行一些清理工作；
- Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等；
- Site Lifecycle 生成项目报告，站点，发布站点；
每套生命周期都由一组阶段（Phase）组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行 mvn clean，这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有 clean 阶段。
三套生命周期相互独立，但各个生命周期中的 phase 却是有顺序的，且后面的 phase 依赖于前面的 phase。执行某个 phase 时，其前面的 phase 会依顺序执行，但不会触发另外两套生命周期中的任何 phase。你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这 3 套生命周期。

6.1 Clean 生命周期

pre-clean 执行一些需要在 clean 之前完成的工作；
clean 移除所有上一次构建生成的文件 — [插件目标] —> maven-clean-plugin:clean；
post-clean 执行一些需要在 clean 之后立刻完成的工作。

6.2 Default 生命周期

default 生命周期是 Maven 生命周期中最重要的一个，它包含了构建项目时真正需要执行的所有步骤。

validate
initialize
generate-sources
process-sources
generate-resources
process-resources         # 复制并处理资源文件，至目标目录，准备打包
compile                   # 编译项目的源代码
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources    # 复制并处理资源文件，至目标测试目录
test-compile              # 编译测试源代码
process-test-classes
test                      # 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署
prepare-package
package                   # 接受编译好的代码，打包成可发布的格式，如JAR
pre-integration-test
integration-test
post-integration-test
verify
install                   # 将包安装至本地仓库，以让其它项目依赖
deploy                    # 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行

6.3 Site 生命周期

pre-site 执行一些需要在生成站点文档之前完成的工作；
site 生成项目的站点文档 — [插件目标] —> maven-site-plugin:site；
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备；
site-deploy 将生成的站点文档部署到特定的服务器上 — [插件目标] —> maven-site-plugin:deploy。

6.4 生命周期与自动化构建

运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行 mvn install 的时候，代码会被编译、测试、打包。这就是 Maven 为什么能够自动执行构建过程的各个环节的原因。此外，Maven 的插件机制是完全依赖 Maven 的生命周期，因此理解生命周期至关重要。

7. 插件和目标

7.1 插件

一个完整的项目构建过程通常包括清理、编译、测试、打包、集成测试、验证、部署等步骤，Maven 从中抽取了一套完善的、易扩展的生命周期。Maven 的生命周期是抽象的，其中的具体任务都交由插件来完成。

Maven 为大多数构建任务编写并绑定了默认的插件，如针对编译的插件：maven-compiler-plugin。用户也可自行配置或编写插件。

7.2 插件的目标

每个插件都能实现多个功能，每个功能就是一个插件目标。Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务。

如执行 mvn install 命令时，调用的插件和执行的插件目标如下：

7.3 插件绑定到生命周期

Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。这一过程是通过将插件的目标（goal）绑定到生命周期的具体阶段（phase）来完成的。

e.g. 将 maven-compiler-plugin 插件的 compile 目标绑定到 default 生命周期的 compile 阶段，完成项目的源代码编译。

a. 内置的绑定

Maven 对一些生命周期的阶段（phase）默认绑定了插件目标，因为不同的项目有 jar、war、pom 等不同的打包方式，因此对应的有不同的绑定关系，其中针对 default 生命周期的 jar 包打包方式的绑定关系如下：

第二列中，冒号后面即是绑定的插件目标，冒号前面是插件的前缀（Plugin Prefix），是配置和使用插件的一种简化方式。

b. 自定义绑定

用户可以根据需要将任何插件目标绑定到任何生命周期的阶段，如：将 maven-source-plugin 的 jar-no-fork 目标绑定到 default 生命周期的 package 阶段，这样，以后在执行 mvn package 命令打包项目时，在 package 阶段之后会执行源代码打包。

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>2.2.1</version>
            <executions>
                <execution>
                    <id>attach-source</id>
                    <phase>package</phase><!-- 要绑定到的生命周期的阶段 -->
                    <goals>
                        <goal>jar-no-fork</goal><!-- 要绑定的插件的目标 -->
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
    <!-- ... -->
</build>

8. 继承&聚合

8.1 继承

由于非 compile 范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。例如：

此时如果项目需要将各个模块的 junit 版本统一为 4.9，那么到各个工程中手动修改无疑是非常不可取的。使用 [继承] 机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。

创建父工程 Maven 项目，唯一需要注意的是：打包方式处要设置为 pom!

在子工程中引用父工程；

<!-- groupId、version 与父工程重复则可以删除 -->
<!-- <groupId>cn.edu.nuist.maven</groupId> -->
<artifactId>HelloFriend</artifactId>
<!-- <version>0.0.1-SNAPSHOT</version> -->

...

<parent>
    <!-- 父工程坐标 -->
    <groupId>cn.edu.nuist.maven</groupId>
    <artifactId>parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <!-- 指定从当前子工程的 pom.xml 出发，查找父工程 pom.xml 的路径 -->
    <relativePath>../parent/pom.xml</relativePath>
</parent>

在父工程中管理依赖，给子工程继承使用；

<groupId>cn.edu.nuist.maven</groupId>
<artifactId>parent</artifactId>
<version>0.0.1-SNAPSHOT</version>

<!--
项目类型：
    pom：用于声明父工程
    jar：用于声明 Java 工程(默认)
    war：用于声明 web 工程
 -->
<packaging>pom</packaging>

<!-- 依赖管理：将 <dependencies> 用 <dependencyManagement> 括起来 -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.9</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

在子项目中重新指定需要的依赖，删除范围和版本号

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
    </dependency>
</dependencies>

8.2 聚合

将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行 clean 操作。而使用了 [聚合] 之后就可以批量进行 Maven 工程的安装、清理工作。

【配置聚合】在总的聚合工程中使用 modules/module 标签组合(module 不分前后顺序)，指定模块工程的相对路径即可。

<modules>
    <module>../Hello</module>
    <module>../HelloFriend</module>
    <module>../A</module>
    ...
</modules>

9. 创建 web 项目

创建简单的 Maven 工程，打包方式选 war 包。

JSP 报错：The superclass "javax.servlet.http.HttpServlet" was not found on the Java Build Path

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>2.5</version>
    <scope>provided</scope>
</dependency>

fix：EL 表达式没有提示问题

<dependency>
    <groupId>javax.servlet.jsp</groupId>
    <artifactId>jsp-api</artifactId>
    <version>2.1.3-b06</version>
    <scope>provided</scope>
</dependency>

posted @ 2020-09-25 17:25 tree6x7 阅读(100) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

Loading

◥(ฅºωºฅ)◤