Maven学习笔记

时间 2019-12-07

标签 maven 学习笔记栏目 Maven 繁體版

原文原文链接

maven学习笔记

先生，您在写代码吗? 不，咱们正在完成一项伟大的工程。

前言

在刚学maven时，我就把maven看成一个引入jar包的工具而已，之前是本身下载jar包，如今是只用在pom文件中填写相应的坐标就能够了。除此以外当咱们须要使用的jar包依赖于另外一个jar包时，maven会自动帮咱们引入适用的版本。这就避免了咱们本身下jar包，而后版本不匹配的问题。除此以外，我还模糊的知道一些maven的聚合和继承，以后在接手项目的时候仍是吃了的大亏。因而打算从新学习一下maven。java

maven是什么?

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
comprehension: the ability to understand something 理解力
maven是一种软件项目管理和理解的工具。基于项目对象模型的概念。程序员

可是在后面的what is maven? 我看到这么一句话:web

We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.
咱们但愿咱们编写的这个工具可以使得java程序员的工做变得简单，使得任何使用该工具的任何java工程更加容易理解。

为何可以帮助开发人员理解工程?

Maven约定了目录架构apache

若是你在java中放配置文件，极可能会报找不到文件的异常。
可是我就是想在java这个文件夹中放配置文件,该怎么办呢? 你须要在pom文件中声明一下
<build>api

<!--配置可在rc/main/java文件夹下编译出xml文件-->


<resources>
        <resource>
            <directory>src/main/java</directory>
            <includes>
                <include>**/*.xml</include>
            </includes>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

Maven的定位

多数博客或者视频都将maven定义为自动化构建工具。
那什么是自动化构建工具呢？
咱们首先来解释构建:服务器

- 编译架构
  - 将java源文件变成字节码，交给JVM去执行
- 部署框架
  - 一个BS项目最终运行的并非动态web工程自己，而是这个动态web工程“编译的结果”
构建各个过程的步骤:maven
- 清理: 将之前编译获得的旧字节码删除掉
- 编译: 将java源代码变成字节码
- 测试: 执行test文件夹中的测试程序
- 报告: 显示测试程序执行的结果
- 打包: 动态Web工程打成war包，Java工程打成jar包
- 安装: Maven的特定概念---将打包获得的文件复制到"仓库"中指定的位置
- 部署: 将动态Web工程生成的war包复制到Servlet容器中指定的目录下,使其能够运行
自动化构建,其实上述步骤,在elipse和IDEA中也能够完成,只不过没那么标准。既然IDE已经能够完成这些工做了，那么还要maven干什么呢?
平常开发中,如下几个步骤是咱们常常走的:ide
- 编译
- 打包
- 部署
- 测试

这几个步骤是程式化的，没有太大的变数或者说根本就没有变数。程序员们很但愿从这些重复的工做中脱身出来,将这些重复的工做交给工具去作。此时Maven的意义就体现出来了，它能够自动的从构建过程当中的起点一直执行到终点。

maven的核心概念

POM
坐标
依赖
仓库
生命周期/插件/目标
继承
聚合

POM

POM: a project object model.项目对象模型

对这个概念老实说,我并无很深的理解,或者说我并不理解项目对象模型的意思。
有资料说项目对象模型就是将Java工程的相关信息封装为对象便于操做和管理的模型。
这个解释的稍微让人那么容易那么一点。
学习Maven就是学习pom.xml文件中的配置

坐标

坐标这个概念我以为和依赖结合起来解释会更好,在没有Maven以前,咱们引入jar包的方式就是先下载，而后在复制在类文件路径下,你的项目须要的jar包，在Maven看来就是你的项目依赖于某些jar包,pom.xml文件中填写对应jar包的位置，就能够引入对应的jar包

使用以下三个向量在 Maven 的仓库中惟一的肯定一个 Maven 工程。

[1] groupid：公司或组织的域名倒序+当前项目名称
[2] artifactId：当前项目的模块名称
[3] version：当前模块的版本

    <groupId>com.atguigu.maven</groupId>
    <artifactId>Hello</artifactId>
    <version>0.0.1-SNAPSHOT</version>

其实引入对象的依赖很是的简单，咱们只用去Maven的中央仓库，输入jar包的名字，选择你须要的版本，而后将复制仓库给出的依赖，粘贴在pom.xml文件中的dependencies标签下就能够了.
步骤以下:
百度搜索Maven

进入以后

好比说我想要Spring-test的jar包

而后选择对应的版本:

仓库

仓库能够理解为存放jar包的地方。

仓库的分类

本地仓库:当前电脑上的部署的仓库目录，为当前电脑上的全部Maven工程服务

远程仓库:

(1) 私服: 搭建在局域网环境中,为局域网范围内的全部Maven工程服务
  (2) 中央仓库: 架设在Internet上,为全世界范围内全部的Maven工程服务。
  (3) 中央仓库镜像: 为了分担中央仓库的流量，提高用户的访问速度。

使用properties标签内自定义标签统一声明版本号

生命周期/插件/目标

什么是Mavende生命周期?

Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就能够自动化的执行构建命 令了。

Maven有三套互相独立的生命周期:

① Clean Lifecycle 在进行真正的构建以前进行一些清理工做
② Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等。
③ Site Lifecycle 生成项目报告，站点，发布站点。

它们是相互独立的，你能够仅仅调用 clean 来清理工做目录，仅仅调用 site 来生成站点。固然你也能够
直接运行 mvn clean install site 运行全部这三套生命周期。
这个生成站点的意思就是: 在本地生成有关你项目的相关信息。
长这个样子:

Clean生命周期:

Clean 生命周期一共包含了三个阶段：
     1 pre-clean 执行一些须要在 clean 以前完成的工做
     2 clean 移除全部上一次构建生成的文件
     3 post-clean 执行一些须要在 clean 以后马上完成的工做

Site生命周期

1 pre-site 执行一些须要在生成站点文档以前完成的工做
2 site 生成项目的站点文档
3 post-site 执行一些须要在生成站点文档以后完成的工做，而且为部署作准备
4 site-deploy 将生成的站点文档部署到特定的服务器上
这里常常用到的是 site 阶段和 site-deploy 阶段，用以生成和发布 Maven 站点，这但是 Maven     至关强大的功能，Manager 比较喜欢，文档及统计数据自动生成，很好看。

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          将最终的包复制到远程的仓库，以让其它开发人员与项目共享

maven生命周期（lifecycle）由各个阶段组成，每一个阶段由maven的插件plugin来执行完成。
当咱们执行的maven命令须要用到某些插件时，Maven的核心程序会首先到本地仓库中查找
本地仓库的默认位置: 能够在配置文件中指定

我查的资料是

依赖

① complie

对主程序是否有效：有效
对测试程序是否有效: 有效
是否参与打包: 参与
是否参与部署: 参与
典型例子: Spring-core

② test

对主程序是否有效: 无效
对测试程序是否有效: 有效
是否参与打包: 不参与
是否参与部署: 不参与
典型例子: junit

③ provided

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

依赖传递性

模块A依赖于模块B。
模块B又依赖于C模块
则模块A内会有C模块。

让咱们把以上的例子在通俗化一些:

模块C引入了Spring-corejar包,
那么模块C中的Maven依赖就会有如下两个jar包。

模块A引入模块B,就会顺带把这两个jar包一并引入。

模块A的pom:

可是如今我并不想要commons-logging这个jar包该怎么办呢?
咱们能够排除依赖:

继承

继承能够帮咱们作什么?

统一管理依赖的版本。

一个典型的例子就是:

如今项目下A、B、C三个模块,三个模块都依赖着不一样的Junit的版本,依赖范围为test时,依赖又不能传递过来,可是咱们但愿可以统一Junit版本,可能有的人天然会想到,你让A、B、C模块pom中的Junit依赖版本写一致不就好了,这也是个办法。可是maven在设计的时候估计也考虑到了这种状况,就是继承了。

继承该如何使用:
①

首先你须要建立一个maven工程,注意指定打包方式为pom    

<groupId>com.cxkStudy.maven</groupId>
 <artifactId>Parent</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <description>学习Maven使用</description>
  <packaging>pom</packaging>

②

再建立一个maven工程,在该模块中指定它的父工程是谁.

 <parent>
        <groupId>com.cxkStudy.maven</groupId>
          <artifactId>Parent</artifactId>
          <version>0.0.1-SNAPSHOT</version>
    </parent>

③

在父项目中肯定子模块的位置
  <modules>
    <module>../studyDenpen</module>
    <module>../Hello</module>
 </modules>

module标签中填的是相对于父项目的位置。
这也就是聚合了.

为何要使用聚合?

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

咱们能够在父工程里面指定Junit的版本,在子模块使用Junit的时候不写版本就行了。

父工程中执行Junit的版本:

<dependencyManagement>
        <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.9</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

子模块中引入Junit的时候不指定版本

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

请注意配置继承后,执行安装命令要先安装父工程。

随着咱们的项目愈来愈大，src下面的包会愈来愈多,我曾经在GitHub下见过一个项目，SRC下面有三十多个包，每一个包下面又有不少类。这代码看的我想吐，不是代码写的烂，而是太混杂了，结构不清晰。咱们能够将咱们的项目根据功能进行拆分,以免src下出现太多的包。好比说，咱们能够将某一个模块专门用来发布咱们写的功能模块，某一个模块放置公共类，某一个模块存放业务代码。这样在结构上会更为清晰，但这只用于比较大的工程,小的工程采用如此的拆分仍是得不偿失。