maven的概念-02

1.仓库

仓库分为两类：

  1）  本地仓库    ->当前电脑上的maven仓库；

        本地仓库的默认目录：

${user.home}/.m2/repository

       如果想修改本地仓库目录：

            打开 maven解压目录/conf下的setting.xml;

            找到<localRepository>标签；解开注释；写入仓库目录；

<localRepository>D:\maven\repository</localRepository>

 

2） 远程仓库    ->局域网私服；

                        ->中央仓库和为其分担压力的镜像；

    添加远程仓库：

        打开 maven解压目录/conf下的setting.xml;

        找到<mirrors>标签；向里面添加一条<mirror>;

    <mirror>

      <id>nexus-public-snapshots</id>

      <mirrorOf>public-snapshots</mirrorOf>

      <url>http://maven.aliyun.com/nexus/content/repositories/snapshots/</url>

    </mirror>

 

3）仓库中的文件：

    maven插件；

    自己开发的项目模块；

    第三方jar包；

 

不管是什么样的jar包，都是按照坐标来建立目录结构的；所以可以通过统一的方式来查询或依赖；

 

2.依赖

依赖是maven中的关键部分，我们使用maven最主要就是使用它的依赖管理功能；

1）关于依赖

    当A jar包用到了B jar包中的某些类时，A就对B产生了依赖；

    在java工程中添加依赖的方式为：在pom.xml 文件的 <dependencys>标签下 ，添加一条<dependency>

    例如：添加junit依赖：

        <dependency>

            <groupId>junit</groupId>

            <artifactId>junit</artifactId>

            <version>4.11</version>

            <!-- 表示开发的时候引入，发布的时候不会加载此包 -->

            <scope>test</scope>

        </dependency>

依赖的格式是按目标jar包的坐标来的；

其中的<scope>标签里的内容表示依赖的范围；

 

2）关于依赖的范围

    常用的依赖范围有三个：

        compile    ->对主程序和测试程序可见；也会参与项目的部署；最主要的依赖范围；

        test        ->只对测试程序可见，不参与部署；

            也就是说，maven标准目录结构中的src/main/java里的程序不可以使用用该jar包里的内容；

            只有src/test/java里的程序可以依赖test范围的jar包；

            项目部署到服务器上时，test范围的jar包不会被部署；

            例如junit;

        provided    ->对主程序和测试程序可见；不参与部署；例如；servelet-api；服务器中自带，不需要部署，但测试程序和主程序还必须依赖；

    

    依赖有效性如图：

 

3）依赖的传递性：

        如果A依赖B;

        B依赖C;

        A是否能使用C取决于B依赖C的范围是否是compile;

 

4）依赖的排除

    如果当某个java工程依赖jar包A;

    而 A依赖 B;

    maven 将自动引入B;

 

    这样会有一个问题：如果B不稳定，不想让B被自动引入；

    可以在依赖A 时排除B;

    配置方式：用<exclusions>标签

<dependency>

    <groupId>com.liusir</groupId>

    <artifactId>hello</artifactId>

    <version>1.0</version>

    <scope>compile</scop>

    

    <exclusions>

        <exclusion>

            <groupId>commons-logging</groupId>

            <artifactId>commons-logging</artifactId>

        </exclusion>

    </exclusions>

</dependency>

 

5）统一化管理依赖jar包版本

    对于同一个 框架的一组jar包，最好使用相同的版本；

    为了方便升级框架，可以将jar包的版本信息统一提取出来；

 

    具体操作：

       1】 统一声明版本号：com.liusir.version是自定义标签

<properties>

    <com.liusir.version>4.02<com.liusir.version>

</properties>

        2】引用前面声明的版本号

        <dependency>

            <groupId>junit</groupId>

            <artifactId>junit</artifactId>

            <version>${com.liusir.version}</version>

        </dependency>

        3】其它用法

            比如声明字符集；当然引用时和版本号的引用方式一样；

<properties>

    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

 

6）依赖的原则

    路径最短者优先：

        比如说，MakeFriend依赖HelloFriend;

        HelloFriend依赖Hello;

        HelloFriend和Hello中都依赖了log4j，由于依赖传递两个log4j都会传递到MakeFriend;

        根据路径最短者优先，MakeFriend 会依赖 HelloFriend中的 log4j;

    

    路径相同时先声明者优先；声明先后顺序是指dependency标签配置的先后顺序；

        比如说，MakeFriend同时依赖HelloFriend 以及 OurFriend;

        HelloFriend和OurFriends中都依赖log4j ；

        而HelloFriend 对两个类的 依赖路径都是 1；

        根据先声明者优先的原则，如果HelloFriend在MakeFriend的pom.xml中dependency先配置，MakeFriend就依赖HelloFriend的log4j ；

    

 

3.maven的生命周期

maven的生命周期定义了各个构建环节执行的顺序；

有了这个清单maven就可以自动化执行构建命令了；

maven有三个独立的生命周期：

    clean lifecycle    ->进行构建之前的一些清理工作；

    default lifecycle    ->构建的核心部分；编译、测试、打包、安装、部署等；

    site lifecycle    ->生成项目报告、站点、发布站点；

 

三个周期之间是相互独立的；

    例如 ：mvn clean 仅能用来清理；mvn site 用来生成站点；也可以 mvn clean install site 同时运行三套生命周期；

 

每套生命周期都由一组阶段组成；

平时输入命令时总对应于一个特定的阶段；

    例如：mvn clean 对应clean周期里的clean阶段；clean周期里还有其它阶段；

 

1）clean周期

    clean周期包含三个阶段：

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

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

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

 

2）site 周期

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

    ②site 生成项目的站点文档

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

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

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

 

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

 

4）生命周期与自动化构建

    运行任何一个阶段时，它前面的所有阶段都会被执行； 

        例如：mvn package打包命名，不仅会打包，还会执行前面的 编译mvn compile、测试mvn test等；

    这也是maven能自动执行构建过程的原因；

    maven的插件机制是完全依赖maven的生命周期的；

 

4.插件和目标

maven 的核心仅定义了抽象的生命周期，具体任务都是插件完成的；

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

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

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

        test-compile 也是插件 maven-compiler-plugin 的一个目标；

        pre-clean 是插件 maven-clean-plugin的一个目标；

 

eclipse中的maven插件：

    eclipse中一般集成了maven插件；windows|preferences|maven 可找到maven设置；

    其中重要的配置有：installtions和user settings

    选 installtions 可设置maven 的位置；

    user settings 指定 conf/settings.xml的位置，进而通过配置来获取本地仓库位置；

 

5.继承

因为依赖的传递规则中，只有compile范围的依赖可以传递；

有时候为了统一管理版本，其它范围的依赖也需要统一；比如junit经常是test范围；

这是可以利用继承机制；

例如：将junit依赖统一提取到父工程；在子工程中声明junit依赖时不指定版本，以父工程为主；

 

①创建Parent工程，打包方式为pom

    ②收集所有非compile范围的依赖信息，使用dependencyManagement标签统一管理

    <dependencyManagement>

            <dependencies>

                <dependency>

                    <groupId>junit</groupId>

                    <artifactId>junit</artifactId>

                    <version>4.9</version>

                    <scope>test</scope>

                </dependency>

            </dependencies>

        </dependencyManagement>

 

    ③在各个子工程中引用父工程

  <parent>

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

            <artifactId>Parent</artifactId>

            <version>0.0.1-SNAPSHOT</version>

            

            <!-- 以当前文件为基准查找父工程中pom.xml文件的相对路径 -->

            <relativePath>../Parent/pom.xml</relativePath>

        </parent>

 

    ④删除子工程中的重复信息

        groupId

        artifactid

    ⑤在子工程中找到被父工程管理的依赖信息，删除版本号部分

    ⑥在父工程中统一修改已管理的依赖信息的版本号，看是否能够控制所有子工程

    

6.聚合

配置继承后，要先安装父工程；否则子工程就没法安装；

如果要将父工程和其所有的子工程一起安装；可以利用聚合；

聚合的作用是一起安装；

配置：在总的聚合工程中加入如下信息

例如：Hello、HelloFriend、MakeFriends都是Parent的子模块；

    可在 Parent工程的pom.xml中添加聚合配置；

    <modules>

        <module>../Hello</module>

        <module>../HelloFriend</module>

        <module>../MakeFriends</module>

    </modules>

输入：mvn install 安装Parent时，其子工程也会一起安装；

注意:聚合和继承没有必然的联系；

 

7.自动化部署（不常用）

 

8.网址

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