大数据入门之maven基础知识介绍

一、为什么要使用Maven
    1.为了减少创建工程就要导入一个jar包到lib目录下，使用了maven后，每个jar包会保存到本地仓库内，新的工程需要jar包的话只需要维护一个文本形式jar包的引用，这个引用叫做“坐标”。
    2.寻找jar包的过程太过艰辛，在工程中只需要以坐标方式依赖一个jar包，maven会自动去中央仓库中去寻找这个jar包。
    3.jar包与jar包之间有太多依赖关系，Maven可以替我们自动的将当前jar包所依赖的其他所有jar包全部导入进来，无需人工参与。
    4.使用Maven就可以自动的处理jar包之间的冲突问题。
    5.将项目拆分成多个工程模块。
    6.实现项目的分布式部署
二、什么是maven
    1.maven的总述
    maven单词本意为专家，内行，是一款自动化构建工具，专注服务于Java平台的项目构建和依赖管理。
    2.什么是构建
    构建就是以我们编写的Java代码、框架配置文件、国际化等其他资源文件、JSP页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。
    3.构建环节
    （1）清理：删除以前的编译结果，为重新编译做好准备。
    （2）编译：将Java源程序编译为字节码文件。
    （3）测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
    （4）报告：在每一次测试后以标准的格式记录和展示测试结果。
    （5）打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java工程对应jar包，Web工程对应war包。
    （6）安装：在Maven环境下特指将打包的结果——jar包或war包安装到本地仓库中。
    （7）部署：将打包的结果部署到远程仓库或将war包部署到服务器上运行。
    4.自动化构建
    清理——编译——测试——报告——打包——安装——部署
    maven可以自动的从构建过程的起点一直执行到终点。
三、maven如何安装与使用
    1.首先在官网https://maven.apache.org/download.cgi下载合适版本的maven，推荐使用3.5.4。
    2.配置环境变量
    3.下载完成后在cmd中查看是否安装成功，在管理员窗口输入myn-v。如果出现maven版本号和java版本号，即为安装成功。
    4.找到maven路径下的conf——settings.xml文件，将如下代码添加到对应位置配置阿里云镜像
    <mirror>
           <id>nexus-aliyun</id>
            <mirrorOf>central</mirrorOf>
            <name>Nexus aliyun</name>
            <url>http://maven.aliyun.com/nexus/content/groups/public</url>
    </mirror>
    在settings.xml中的<profiles></profiles>标签中加入如下内容编译
    <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>
    Maven本身的打包插件不负责将依赖的jar包一并打入到jar包中。因此需要一款能够将项目所依赖的jar包 一并打入到jar中的插件来解决这些问题。在pom.xml中加入如下内容:
<build>
    <plugins>
        <plugin>
            <artifactId>maven-assembly-plugin</artifactId>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
            <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
            </executions>
        </plugin>
    </plugins>
</build>
四、maven的核心概念
    1.POM
    Project Object Model：项目对象模型。将Java工程的相关信息封装为对象作为便于操作和管理的模型。Maven工程的核心配置。可以说学习Maven就是学习pom.xml文件中的配置。
    2.约定的目录结构
    约定>配置>编码，能用配置解决的问题就不编码，能基于约定的就不进行配置。
    3.坐标
    使用如下三个向量在Maven的仓库中唯一的确定一个Maven工程。
    （1）groupId：公司或组织的域名倒序+当前项目名称
    （2）artifactId：当前项目的模块名称
    （3）version：当前模块的版本
    在项目的pom.xml文件中存储坐标
<?xml version="1.0" encoding="UTF-8"?>
<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>com.a.maven</groupId>
    <artifactId>HelloWorld</artifactId>
    <version>1.0-SNAPSHOT</version>
</project>
    如何通过坐标到仓库中查找jar包？
    （1）将gav三个向量连起来
    com.a.maven + HelloWorld + 1.0-SNAPSHOT
    （2）以连起来的字符串作为目录结构到仓库中查找
    com/a/maven/HelloWorld/1.0-SNAPSHOT/Hello-1.0-SNAPSHOT.jar
    4.依赖
    当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。
<dependencies>
    <!--坐标-->
    <dependency>
        <groupId>com.a.maven</groupId>
        <artifactId>HelloWorld</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
    
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>
    依赖的范围
    1）compile（默认就是这个范围）
    （1）main目录下的Java代码可以访问这个范围的依赖
    （2）test目录下的Java代码可以访问这个范围的依赖
    （3）部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下
例如：对HelloWorld的依赖。主程序、测试程序和服务器运行时都需要用到。
    2）test
    （1）main目录下的Java代码不能访问这个范围的依赖
    （2）test目录下的Java代码可以访问这个范围的依赖
    （3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
    例如：对junit的依赖。仅仅是测试程序部分需要。
    3）provided
    （1）main目录下的Java代码可以访问这个范围的依赖
    （2）test目录下的Java代码可以访问这个范围的依赖
    （3）部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下
    例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。
    依赖的原则：解决jar包冲突
    1）路径最短者优先
    2）路径相同时先声明者优先，这里“声明”的先后顺序指的是dependency标签配置的先后顺序。
    依赖的排除 
    假设当前工程为MakeFriend，直接依赖OurFriends。
    OurFriends依赖commons-logging的1.1.1对于MakeFriend来说是间接依赖。
    当前工程MakeFriend直接依赖commons-logging的1.1.2
    加入exclusions配置后可以在依赖OurFriends的时候排除版本为1.1.1的commons-logging的间接依赖
<dependency>
    <groupId>com.atguigu.maven</groupId>
    <artifactId>OurFriends</artifactId>
    <version>1.0-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-context，springmvc等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-context的同时使4.1.1的springmvc。
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>4.0.0.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>4.0.0.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>4.0.0.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-orm</artifactId>
    <version>4.0.0.RELEASE</version>
</dependency>
    问题是如想要将这些jar包的版本统一升级为4.1.1，是不是要手动一个个修改呢？显然，我们有统一配置的方式：
<!--统一管理当前模块的jar包的版本-->
<properties>
    <spring.version>4.0.0.RELEASE</spring.version>
</properties>

……
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-orm</artifactId>
    <version>${spring.version}</version>
</dependency>
这样一来，进行版本调整的时候只改一改地方就行了。
    6.仓库
    1）分类
    （1）本地仓库：为当前本机电脑上的所有Maven工程服务。
    （2）远程仓库
        a）私服：架设在当前局域网环境下，为当前局域网范围内的所有Maven工程服务。
        b）中央仓库：架设在Internet上，为全世界所有Maven工程服务。
        c）中央仓库的镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的响应用户请求。
    2）仓库中的文件
    （1）Maven的插件
    （2）我们自己开发的项目的模块
    （3）第三方框架或工具的jar包
    7.生命周期
    Maven生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven就可以自动化的执行构建命令了。Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要。
    Maven有三套相互独立的生命周期，它们是相互独立的，分别是： 
    Clean Lifecycle在进行真正的构建之前进行一些清理工作。
    Default Lifecycle构建的核心部分，编译，测试，打包，安装，部署等等。
    Site Lifecycle生成项目报告，站点，发布站点。
     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将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。
    8.插件与目标
    （1）Maven的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
    （2）每个插件都能实现多个功能，每个功能就是一个插件目标。
    （3）Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
    例如：compile就是插件maven-compiler-plugin的一个功能；pre-clean是插件maven-clean-plugin的一个目标。
五、继承
    由于非compile范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。为了避免每一个都手动处理，此时使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。
    1、创建父工程
    父工程的打包方式为pom
    <groupId>com.atguigu.maven</groupId>
         <artifactId>Parent</artifactId>
         <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    父工程只需要保留pom.xml文件即可
    2.在子工程引用父工程
    <parent>
        <!-- 父工程坐标 -->
        <groupId>...</groupId>
                <artifactId>...</artifactId>
        <version>...</version>

        <!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径-->
        <relativePath>..</relativePath>
    </parent>
    <!--继承-->
    <parent>
            <groupId>com.a.maven</groupId>
            <artifactId>Parent</artifactId>
            <version>1.0-SNAPSHOT</version>
        <!--指定从当前pom.xml文件出发寻找父工程的pom.xml文件的相对路径-->
        <relativePath>../Parent/pom.xml</relativePath>
    </parent>
    此时如果子工程的groupId和version如果和父工程重复则可以删除。
    3.在父工程中管理依赖
        将Parent项目中的dependencies标签，用dependencyManagement标签括起来
    <!--依赖管理-->
    <dependencyManagement>
            <dependencies>
                    <dependency>
                            <groupId>junit</groupId>
                            <artifactId>junit</artifactId>
                            <version>4.0</version>
                            <scope>test</scope>
                    </dependency>
            </dependencies>
    </dependencyManagement>
    在子项目中重新指定需要的依赖，删除范围和版本号
    <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
    </dependency>
六、聚合
    将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean操作。而使用了聚合之后就可以批量进行Maven工程的安装、清理工作。

    在总的聚合工程中使用modules/module标签组合，指定模块工程的相对路径即可
    <!--聚合-->
    <modules>
            <module>../MakeFriend</module>
            <module>../OurFriends</module>
            <module>../HelloFriend</module>
            <module>../Hello</module>
    </modules>
    Maven可以根据各个模块的继承和依赖关系自动选择安装的顺序
七、maven库站
    我们可以到http://mvnrepository.com/搜索需要的jar包的依赖信息。
    http://search.maven.org/