浅谈maven自动化构建工具

转载https://blog.csdn.net/zxm1306192988/article/details/76209062

Maven是什么[what]

1.Maven 是 Apache 软件基金会组织维护的一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理 构建工具的发展：Make→Ant→Maven→Gradle

2.构建：就是以我们编写的Java代码、框架配置文件、国际化等其他资源文件、jsp页面和图片等静态资源作为"原材料"，去"生产"出一个可以运行的项目的过程。

3.eclipse中的项目与tomcat中编译结果对比：（这就是因为项目里带的有Java运行环境runtime）

4.maven就是这个意思类似

构建过程中的几个主要环节

①清理：删除以前的编译结果，为重新编译做好准备。

②编译：将Java源程序编译为字节码文件。

③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。

④报告：将每一次测试后以标准的格式记录和展示测试结果。

⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。

⑥安装：在Maven环境下特指将打包的结果——Jar包或War包安装到本地仓库中。

⑦部署：将打包的结果部署到远程仓库或将war包部署到servlet容器下指定的目录上运行。

自动化构建

安装Maven核心程序

我用的3.3.9

Maven的核心概念

1. 约定的目录结构
2. POM
3. 坐标
4. 依赖
5. 仓库
6. 生命周期/插件/目标
7. 继承
8. 聚合

Maven常用命令

1.注意：执行与构建过程相关的Maven命令，必须进入pom.xml 所在的目录。

2.常用命令

【1】mvn clean : 清理

【2】mvn compile : 编译主程序

【3】mvn test-compile : 编译测试程序

【4】mvn test : 执行测试

【5】mvn package : 打包

【6】mvn install ： 安装

【7】mvn site ：生成站点

关于联网问题

1.Maven 的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须有特定的插件来完成。而插件本身不包含在Maven核心程序中。

2.当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找。

3.本地仓库的默认位置：[系统登陆用户的家目录] \ .m2\repository

4.Maven核心程序如果在本地仓库中找不到需要的插件，那么它会自动连接外网，到中央仓库下载。

5.如果此时无法连接外网，则构建失败。

6.修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件

①找到Maven解压目录\conf\settings.xml

②在setting.xml 文件中找到 localRepository 标签

③将 < localRepository>/path/to/local/repo< /localRepository>从注释中取出

④将标签体内容修改为自定义的Maven仓库目录

POM

 

 

1.含义：

Project Object Model 项目对象模型

    DOM ：Document Object Model 文档对象模型

2.pom.xml 对于 Maven工程是核心配置文件

与构建过程相关的一切设置都在这个文件中进行配置。

重要程度相当于web.xml 对于动态web工程

坐标

 

 

 

1.数学中的坐标：

①在平面中，使用X,Y坐标可以唯一的定位平面中任何一个点。

②在空间中，使用X,Y，Z三个向量可以唯一的定位空间中的任何一个点。

2.Maven的坐标：

使用下面三个向量在仓库中唯一定位一个Maven工程

①groupid:公司或组织域名倒序+项目名

< groupid>com.atguigu.maven< /groupid>

②artifactid:模块名

< artifactid>Hello< /artifactid>

③version：版本

< version>1.0.0< /version>

 

3.Maven 工程的坐标与仓库中路径的对应关系，以spring为例

< groupId>org.springframework< /groupId>

< artifactId>spring-core< /artifactId>

< version>4.0.0.RELEASE< /version>

 

org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar

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

仓库

1.仓库的分类

①本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务

②远程仓库

（1）私服：搭建在局域网环境中，为局域网范围内的所有Maven工程服务

（2）中央仓库：假设在Internet上，为全世界所有Maven工程服务

（3）中央仓库镜像：为了分担中央仓库流量，提升用户访问速度

2.仓库中保存的内容：Maven工程 包含以下

①Maven自身所需要的插件

②第三方框架或工具的jar包

③我们自己开发的Maven工程

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

依赖

1.概念上的描述。

当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。Maven解析依赖信息时会到仓库中查找被依赖的jar包。
对于我们自己开发的Maven工程，要使用mvn install 命令安装后就可以进入仓库。

 

2.依赖的范围
①从项目结构角度理解compile和test的区别

compile范围依赖

》对主程序是否有效：有效

》对测试程序是否有效：有效

》是否参与打包：参与

》是否参与部署：参与

》典型例子：spring-core

 

test范围依赖

》对主程序是否有效：无效

》对测试程序是否有效：有效

》是否参与打包：不参与

》是否参与部署：不参与

》典型例子：Junit

 

 

②从开发和运行这两个阶段理解compile 和 provided 的区别

》对主程序是否有效：有效
》对测试程序是否有效：有效
》是否参与打包：不参与
》是否参与部署：不参与
》典型例子：Servlet-api.jar

 

 

③有效性总结

 

3.依赖的传递性
A依赖B，B依赖C，A能否使用C呢？要看B依赖C的范围是不是compile

4.依赖的排除
如果我们当前工程中引入了一个依赖是A，而A又依赖了B，那么Maven会自动将A依赖的B引入当前工程，但是个别情况下B有可能是一个不稳定版本，或对当前工程有不良影响。这时我们可以在引入A的时候将B排除。

①情景举例

②配置方式

<dependency>

<groupId>com.atguigu.maven</groupId>

<artifactId>HelloFriend</artifactId>

<version>0.0.1-SNAPSHOT</version>

<type>jar</type>

<scope>compile</scope>

<exclusions>

< exclusion>

<groupId>commons-logging</groupId>

<artifactId>commons-logging</artifactId>

</ exclusion>

</exclusions>

</dependency>

 

③排除后的效果

 

5.统一管理所依赖 .jar 包的版本
对同一个框架的一组jar包最好使用相同的版本。为了方便升级架构，可以将jar包的版本信息统一提取出来

①统一声明版本号

其中 atguigu.spring.version 部分是自定义标签。

②引用前面声明的版本号

③其他用法

 

 

 

 

 

 

 

 

6.依赖的原则，解决jar包冲突

 

 

生命周期

1.

各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。

2.

Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。

3.

Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中各个阶段：不论现在要执行生命周期中的哪一阶段，都是从这个生命周期最初的位置开始执行。

4.Maven有三套相互独立的生命周期，分别是：

①Clean Lifecycle 在进行真正的构建之前进行一些清理工作。

②Default Lifecycle 构建的核心部分，编译、测试、打包、安装、部署等等。

③Site Lifecycle 生成项目报告，站点，发布站点。

 

他们相互独立。也可以直接运行 mvn clean install site 运行所有这三套生命周期。

 

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行 mvn clean，这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期，也有 clean 阶段。

5.Clean声明周期

①pre-clean 执行一些需要在clean之前完成的工作

②clean 移除所有上一次构建生成的文件

③post-clean 执行一些需要在clean 之后立刻完成的工作

6.Default声明周期

Default 生命周期是 Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里，只解释一些比较重要和常用的阶段：

validate

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 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

7.Site生命周期

①pre-site 执行一些需要在生成站点文档之前完成的工作

②site 生成项目的站点文档

③post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备

④site-deploy 将生成的站点文档部署到特定的服务器上

 

这里经常用到的是 site 阶段和 site-deploy 阶段，用以生成和发布 Maven 站点，这可是 Maven 相当强大的功能，Manager 比较喜欢，文档及统计数据自动生成，很好看。

8.插件和目标

Maven的核心仅仅定义了抽象的声明周期，具体的任务都是交由插件完成的。

每个插件都实现多个功能，每个功能就是一个插件目标

Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。

可以将目标看做"调用插件功能的命令"

 

例如：compile 就是插件 maven-compiler-plugin 的一个目标；pre-clean 是插件 maven-clean-plugin 的一个目标。

在Eclipse中使用Maven

1.Maven插件的设置： Window->Preferences->Maven

①installations : 指定Maven核心程序的位置。默认是插件自带的Maven程序，改为我们自己解压的那个。

②user settings : 指定Maven核心程序中 conf/settings.xml 文件的位置，进而获取本地仓库的位置。

2.基本操作
①创建Maven版的Java工程
创建时勾选上 Create a simple project(skip archetype selection)

创建的Maven工程默认使用的是JDK1.5，打开Maven核心程序settings.xml文件，找到profiles标签，加入如下配置，即可更改

<profile>

<id>jdk-1.7</id>

<activation>

<activeByDefault>true</activeByDefault>

<jdk>1.7</jdk>

</activation>

<properties>

<maven.compiler.source>1.7</maven.compiler.source>

<maven.compiler.target>1.7</maven.compiler.target>

<maven.compiler.compilerVersion>1.7</maven.compiler.compilerVersion>

</properties>

</profile>

 

②创建Maven版的Web工程
1、New Maven project时，Packaging 选择 war（之前默认是jar）

2、调整web目录结构，在项目上点右键 -> properties->Project Facets -> 把Dynamic Web Module 勾选去掉，并Apply -> 将Dynamic Web Module 重新勾选 -> 点击Further configuration available -> 修改 Content directory为src/main/webapp -> Apply 即在Maven工程上生成动态Web目录结构

3、新建jsp文件发现报错：The superclass "javax.servlet.http.HttpServlet" was not found on the Java Build Path

因为缺少Tomcat 运行时环境

以Maven方式添加：

在pom.xml文件中添加

4、jsp写入EL表达式时发现报错：javax.servlet.jsp cannot be resolved to a type
将JSPAPI导入
在pom.xml文件中添加

 

注意：scope一定要是provided，不然jar包冲突，运行时会报空指针异常

③执行Maven命令
选中pom.xml 右键 Run As->Maven build…->Goals->输入 compile ->点击 run

继承

1.现状 三个maven

Hello依赖的Junit：4.0

HelloFriend依赖的Junit：4.0

MakeFriends依赖的Junit：4.9

 

由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。

2.需求：统一管理各个模块工程中对Junit依赖的版本。

3.解决思路：将Junit依赖统一提取到"父"工程中，在子工程中声明Junit依赖是不指定版本，以父工程中统一设定的为准。同时也便于修改。

4.操作步骤：

①创建一个Maven工程作为父工程。注意：打包方式为pom （既不是jar也不是war）

②在子工程中声明对父工程的引用

③将子工程的坐标中与父工程坐标中重复的内容删除

④在父工程中统一管理Junit的依赖

⑤在子工程中删除Junit依赖的版本号部分

注意：配置集成后，执行安装命令时要先安装父工程。

 

聚合

1.作用：一键安装各个模块工程。

2.配置方式：在一个"总的聚合工程"中配置各个参与聚合的模块

3.使用方式：在聚合工程的pom.xml 上点右键->run as->maven install

 

 

 

 

Maven_Web工程的自动部署

在pom.xml 中添加如下配置：

<!--配置当前工程构建过程中的特殊设置 -->

<build>

<finalName>AtguiguWeb</finalName>

<!-- 配置构建过程中需要使用的插件 -->

<plugins>

<plugin>

<!-- cargo是一家专门从事启动Servlet容器的组织 -->

<groupId>org.codehaus.cargo</groupId>

<artifactId>cargo-maven2-plugin</artifactId>

<version>1.2.3</version>

<!-- 针对插件进行的配置 -->

<configuration>

<!-- 配置当前系统中容器的位置 -->

<container>

<containerId>tomcat6x</containerId>

<home>D:\DevInstall\apache-tomcat-6.0.39</home>

</container>

<configuration>

<type>existing</type>

<home>D:\DevInstall\apache-tomcat-6.0.39</home>

<!-- 如果Tomcat端口为默认值8080则不必设置该属性 -->

<properties>

<cargo.servlet.port>8989</cargo.servlet.port>

</properties>

</configuration>

</configuration>

<!-- 配置插件在什么情况下执行 -->

<executions>

<execution>

<id>cargo-run</id>

<!-- 生命周期的阶段 -->

<phase>install</phase>

<goals>

<!-- 插件的目标 -->

<goal>run</goal>

</goals>

</execution>

</executions>

</plugin>

</plugins>

</build>

 

执行mvn deploy 命令

Maven 酷站

我们可以到 http://mvnrepository.com/搜索需要的 jar 包的依赖信息。