maven的使用

maven的使用

官网下载地址：http://maven.apache.org/download.cgi

maven中央仓库 : https://mvnrepository.com/

将下载的 maven 压缩包解压到电脑的某个盘符，我这里是 D:\JavaTools\apache-maven-3.3.9

　　①、右键---计算机属性----高级系统设置---高级---环境变量---系统变量----新建    

　　　　变量名：MAVEN_HOME

　　　　变量值：D:\JavaTools\apache-maven-3.3.9　　　　　　PS：这个值是 maven 压缩包解压的位置

　　②、将 MAVEN_HOME 添加到 path 目录下

　　选择 path---编辑---新建---将 %MAVEN_HOME%\bin  添加进去，然后点击确定就可以了

;%M2_HOME%\bin

mvn -version

eclipse中配置Maven

1 在window-preference中搜索maven 在1 Maven Installation 找到Maven安装路径的bin的路径

2  User setting 找到Maven的setting 及本地仓库

引入Maven项目的时候，有时候启动的时候项目以前好好的突然就爆错了，是因为Maven的引入依赖没有了。可以右击项目选择Project References查看，发现里面没有Maven的依赖。

这时候我们选择项目，右击项目，找到Maven选项，选择UPdate Project即可

Maven的setting文件的配置

在进行安装配置maven工具的时候，首先就需要对maven安装目录下有个config文件夹，在文件夹下有settings.xml文件。settings里面就是配置maven工程的一些本地仓库地址（项目使用的某些jar下载并且安装到本机中），远程仓库（如果本机没有需要的jar，则从远程获取。）的配置等信息。

配置maven的M2_HOME路径，添加maven安装目录/bin到path环境。打开%M2_HOME%/conifg/settings.xml文件，在文件中可以看到localRepository配置的就是本地仓库，本地仓库地址的目录最好是全英文格式，不要包含汉字空格等其他特殊字符。

mirror表示的是访问镜像。如果本地仓库没有项目所需要的jar包，就会通过这里的mirror配置的url地址进行从远程仓库获取需要的jar，同事将这个jar添加到本地目录中，当再次使用的时候，就会直接从本地仓库中直接获取。

配置阿里云镜像

配置阿里云镜像下载的时候会很快

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

eclipse创建一个 Maven 工程

　第一步：File-->New--->Maven Project

　第二步：勾上 Create a simple project ,然后点击 next

　第三步：填写 Group Id 和 Artifact Id

groupid和artifactId被统称为“坐标”是为了保证项目唯一性而提出的，如果你要把你项目弄到maven本地仓库去，你想要找到你的项目就必须根据这两个id去查找。

　　groupId一般分为多个段，这里只说两段，第一段为域，第二段为公司名称。域又分为org、com、cn等等许多，其中org为非营利组织，com为商业组织。举个apache公司的tomcat项目例子：这个项目的groupId是org.apache，它的域是org（因为tomcat是非营利项目），公司名称是apache，artigactId是tomcat。

　　ArtifactID就是项目的唯一的标识符，实际对应项目的名称，就是项目根目录的名称。比如我创建一个项目，我一般会将groupId设置为com.my.com表示域，ys是我个人姓名缩写，Artifact Id设置为hellomaven，表示你这个项目的名称是hellomaven，依照这个设置，你的包结构最好是com.my.hellomaven打头的，如果有个StudentDao，它的全路径就是com.my.hellomaven.dao.StudentDao

Maven Java工程的目录结构 

①、我们根据上面的步骤，创建出如下的 maven 工程：

　对每个目录结构的解析如下：

　②、为什么 maven 工程的目录结构要这样呢？

　　1、Maven 要负责项目的自动化构建，以编译为例，Maven 要想自动进行编译，那么它必须知道 Java 的源文件保存在哪里，这样约定之后，不用我们手动指定位置，Maven 能知道位置，从而帮我们完成自动编译。

　　2、遵循 约定>>>配置>>>编码。即能进行配置的不要去编码指定，能事先约定规则的不要去进行配置。这样既减轻了劳动力，也能防止出错。

　　③、pom.xml 文件

　　Project Object Model 项目对象模型，Maven 的核心配置文件，pom.xml，与构建过程相关的一切设置都在这个文件中进行配置。

<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.my</groupId>
  <artifactId>hellomaven</artifactId>
  <version>0.0.1-SNAPSHOT</version>
   
  <dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.0</version>
        <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Maven 中的坐标

　　　　俗称 gav：使用下面三个向量子仓库中唯一定位一个 Maven 工程

　　　　在项目中的 pom.xml 文件中，我们可以看到下面gav的定义：

　　　　1、groupid:公司或组织域名倒序 

　　　　　　<groupid>com.ys.maven</groupid>

　　　　2、artifactid:模块名，也是实际项目的名称

　　　　　　<artifactid>Maven_05</artifactid>

　　　　3、version:当前项目的版本

Maven 的常用命令

1、mvn compile 编译,将Java 源程序编译成 class 字节码文件。
2、mvn test 测试，并生成测试报告
3、mvn clean 将以前编译得到的旧的 class 字节码文件删除
4、mvn pakage 打包,动态 web工程打 war包，Java工程打 jar 包。
5、mvn install 将项目生成 jar 包放在仓库中，以便别的模块调用

　　①、compile:将Java 源程序编译成 class 字节码文件。

　　第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...

　第二步：在第一步执行完后弹出来的对话框中，输入 compile，然后点击 Run 按钮

　第三步：查看控制台

　第四步：在 target 目录下，我们会发现编译生成的 class 文件

　②、test:测试，并生成测试报告

　　第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...,然后在弹出框中输入 test

　　　　　　或者选择 pom.xml 文件，右键--->Run As------>6 Maven test，如下图

　　第二步：查看控制台

　　分析测试程序，我们传入的参数是Tom，而我们希望的是maven，很显然是不相等的，那么测试失败

生成的测试报告可以在如下目录查看：target/surefire-reports

③、mvn clean 将以前编译得到的旧的 class 字节码文件删除

　　第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...,然后在弹出框中输入 clear

　　　　或者选择 pom.xml 文件，右键--->Run As------>3 Maven clear，如下图

　第三步：发现 mvn compile 编译好的文件这时已经清除了

　④、mvn pakage 打包,动态 web工程打 war包，Java工程打 jar 包。

打包没有mvn pakage，选择Maven build 第二个

第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...,然后在弹出框中输入 package

　第三步：进入到 target 目录，会发现打出来的 jar 包

　

⑤、mvn install 将项目生成 jar 包放在仓库中，以便别的模块调用

 　　这里我们就不截图了，执行命令后，进入到 settings.xml 文件中配置的仓库，你会发现生成的 jar包

依赖的详细配置

<project>     
    <dependencies>
        <dependency>
            <groupId>junit</groupId>     
            <artifactId>junit</artifactId>     
            <version>3.8.1</version>
            <type>...</type>
            <scope>...</scope>
            <optional>...</optional>
            <exclusions>     
                <exclusion>     
                  <groupId>...</groupId>     
                  <artifactId>...</artifactId>     
                </exclusion>
          </exclusions>     
        </dependency>        
      </dependencies>     
</project>

　　①、dependencies：一个 pom.xml 文件中只能存在一个这样的标签。用来管理依赖的总标签。

　　②、dependency:包含在dependencies标签中，可以有无数个，每一个表示一个依赖

　　③、groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖。

　　④、type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar。

　　⑤、scope：依赖的范围，默认值是 compile。后面会进行详解。

　　⑥、optional：标记依赖是否可选。

　　⑦、exclusions：用来排除传递性依赖，后面会进行详细介绍。

依赖的范围 scope 

一般情况下，我们对前面三个依赖用的比较多。下面的主程序表示maven 目录结构 src/main/java.测试程序目录结构为：src/test/java

 　　1、compile 范围依赖

　　　　对主程序是否有效：有效

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

　　　　是否参与打包：参与

　　　　是否参与部署：参与

　　　　典型例子：log4j

　　2、test 范围依赖

　　　　对主程序是否有效：无效

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

　　　　是否参与打包：不参与

　　　　是否参与部署：不参与

　　　　典型例子：Junit

　　3、provided 范围依赖

　　　　对主程序是否有效：有效

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

　　　　是否参与打包：不参与

　　　　是否参与部署：不参与

　　　　典型例子：servlet-api.jar，一般在发布到 服务器中，比如 tomcat，服务器会自带 servlet-api.jar 包，所以provided 范围依赖只在编译测试有效。

 　　4、runtime 范围依赖：在测试、运行的时候依赖，在编译的时候不依赖。例如：JDBC驱动，项目代码只需要jdk提供的jdbc接口，只有在执行测试和运行项目的时候才需要实现jdbc的功能。

依赖的传递

　比如我们创建三个Maven 工程，maven-first,maven-second以及maven-third,而third依赖于second，second又依赖于first，那么我们说 second 是 third 的第一直接依赖，first是second的第二直接依赖。而first是third的间接依赖。

依赖之间的传递如下图：第一列表示第一直接依赖，第一行表示第二直接依赖

1、当第二依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致。
2、当第二直接依赖的范围是test的时候，依赖不会得以传递。
3、当第二依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为 provided；
4、当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递的依赖范围为runtime；

依赖另一个项目

另一个项目打包方式为jar

  <groupId>com.java.user</groupId>
  <artifactId>user-dao</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

引入上面的项目

  <groupId>com.java.user</groupId>
  <artifactId>user-service</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

 

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

  <dependencies>   
   <dependency>
    	<groupId>com.java.user</groupId>
    	<artifactId>user-dao</artifactId>
    	<version>0.0.1-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

依赖的排除

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

　　比如：我们在Maven_first 中添加 spring-core,maven 会自动将 commons-logging添加进来，那么由于 Maven_second 是依赖 Maven_first  的，那么 Maven_second  中将存在 spring-core(自带了commons-logging)，这时候我们不想要 commons-logging

exclusions：用来排除传递性依赖

我们在 Maven_second 的 pom.xml 文件中添加如下代码：

Maven_second 的 commons-logging 已经移除了

在maven中存在两种冲突方式：一种是跨pom文件的冲突，一致是同一个pom文件中的冲突。

　①、跨 pom 文件，路径最短者优先。比如我们在 Maven_first 中的 Junit 是4.9版本的，Maven_second 中的 Junit 是4.8版本的，那么Maven_third 中的 Junit 将会是那个版本呢？

由于 Maven_second 是 Maven_third 的直接依赖，明显相比于 Maven_first 路径要短，所以 Maven_third 的 Junit 版本与 Maven_second 保持一致。

　②、同一个pom.xml 文件，先申明者优先。

可选依赖

　Optional标签标示该依赖是否可选，默认是false。可以理解为，如果为true，则表示该依赖不会传递下去，如果为false，则会传递下去。

我们是在 Maven_second 的 pom 文件中设定 Junit 不可传递，那么Maven_third 工程中将不会有来自 Maven_second 的 Junit 的传递。

 Maven生命周期

，生命周期可以理解为项目构建步骤的集合，它定义了各个构建环节的执行顺序，有了这个顺序，Maven 就可以自动化的执行构建命令。

　　Maven 的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。有三套相互独立的生命周期，各个构建环节执行顺序不能打乱，必须按照既定的正确顺序来执行。

Maven拥有三套独立的生命周期

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

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

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

　　这三个都是相互独立的。你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。当然，也可以直接运行 mvn claen install site 运行所有这三套生命周期。

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

pre-clean 执行一些需要在clean之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean之后立刻完成的工作

我们前面讲的执行命令 mvn -clean,也就等同于 Clean 生命周期中的第一个阶段 mvn pre-clean clean。注意有 Clean 声明周期，而这个声明周期中又有 clean 阶段。

只要执行后面的命令，那么前面的命令都会执行，不需要再重新去输入命令。

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

在maven中，只要在同一个生命周期，你执行后面的阶段，那么前面的阶段也会被执行，而且不需要额外去输入前面的阶段。

　执行 mven compile 命令，根据上面的声明周期，它会默认执行前面五个个步骤也就是　　　

validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码

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

pre-site 执行一些需要在生成站点文档之前完成的工作
site 生成项目的站点文档
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
site-deploy 将生成的站点文档部署到特定的服务器上

　这里经常用到的是 site 阶段和 site-deploy 阶段，用来生成和发布 maven 站点，这是 Maven 比较强大的功能，文档及统计数据自动生成。由于现在的系统会有专门工具来生成文档或报表。所以这个功能也是比较鸡肋吧，不够简洁和美观，用的不太多。

Maven 插件

我们也可以说 Maven 是一个执行插件的框架，每一个任务实际上都是有插件来完成。进一步说每个任务对应了一个插件目标（goal），每个插件会有一个或者多个目标，例如maven-compiler-plugin的compile目标用来编译位于src/main/java/目录下的主源码，testCompile目标用来编译位于src/test/java/目录下的测试源码。

配置编译插件

一般我们创建一个 Maven 工程，就算指定了 JDK 的版本，但是你执行 update project 操作，一般 Maven 工程会自动恢复到默认的 JDK 版本，有可能是1.4，有可能是1.5（和 Maven 版本有关）。

<build>
    <plugins>
        <!-- 编译插件，指定 JDK 的版本为1.7 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>

添加一个 tomcat 插件

New maven project，注意打包方式为 war

右击项目名，选择 properties，选择Project Facets

将 Dynamic Web Module 取消，点击 Apply

将 Dynamic Web Module 重新勾选，点击 下方生成的超链接

点击超链接，修改目录结构，然后点击 OK，创建 Maven Web 工程完成

添加 tomcat 插件

我们在上面创建的 web 工程，可以输入  tomcat:run 来使用默认的 tomcat 插件去启动 web 工程，但是默认的插件版本有点低，我们可以手动添加插件。

<build>
    <plugins>
        <!--配置tomcat 插件  -->
    <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <configuration>
            <port>8080</port><!--端口号  -->
            <path>/</path>
        </configuration>
    </plugin>
</plugins>

　选择 pom.xml 文件，右键--->Run As ---->2 Maven build...之后弹出来的对话框中，输入 compile，然后点击 Run 按钮

执行命令是输入：tomcat7:run

继承

有三个 Maven 工程，每个工程都依赖某个 jar 包，比如 Junit，由于 test 范围的依赖不能传递，它必然会分散在每个工程中，而且每个工程的jar 包版本可能不一致。那么如何管理各个工程中对于某个 jar 包的版本呢？

将那个 jar 包版本统一提取到 “父" 工程中，在子工程中声明依赖时不指定版本，以父工程中统一设定的为准，同时也便于修改。

操作步骤：

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

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.my.maven</groupId>
  <artifactId>Parent</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>pom</packaging>
  
  <modules>
  	<module>../user-dao</module>
  	<module>../user-service</module>
  </modules>
  
  <properties>
  	<spring.version>4.1.7.RELEASE</spring.version>
  	<junit.version>4.12</junit.version>
  	<log4j.version>1.2.17</log4j.version>
  </properties>

  <dependencyManagement>
  	<dependencies>
		
		<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>${log4j.version}</version>
		</dependency>
  	</dependencies>
  </dependencyManagement>
</project>

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

<!--子工程中声明对父工程的引用  -->
  <parent>
      <groupId>com.my.maven</groupId>
      <artifactId>Parent</artifactId>
      <version>0.0.1-SNAPSHOT</version>
      <!-- 以当前工程文件为基准的父工程 pom.xml文件的相对路径（可以不配置） -->
      <relativePath>../Parent/pom.xml</relativePath>
  </parent>

　③、将子工程的坐标中与父工程坐标重复的内容删除（不删除也可以，为了简洁）

　④、在父工程中统一那个 jar 的版本依赖

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

　　dependencyManagement标签管理的依赖，其实没有真正依赖，它只是管理依赖的版本。

　　⑤、在子工程中删除 Junit 的版本号

  <parent>
      <groupId>com.my.maven</groupId>
      <artifactId>Parent</artifactId>
      <version>0.0.1-SNAPSHOT</version>
      <!-- 以当前工程文件为基准的父工程 pom.xml文件的相对路径（可以不配置） -->
      <relativePath>../Parent/pom.xml</relativePath>
  </parent>
  
  <artifactId>user-dao</artifactId>
  <packaging>jar</packaging>

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


   <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

　以后要更改版本号，我们只需要更改父工程中的版本号即可！！！

　　⑥、父工程通过 properties 统一管理版本号

　　我们可以通过<properties></properties>自定义标签，然后在标签里面填写常量，这种方法不仅可以用来管理版本号，还可以用来管理比如设置某种编码等等。

聚合

　在真实项目中，一个项目有表现层、业务层、持久层等。我们在用Maven 管理项目的时候，通常为创建多个 Maven 工程，也就是一个项目的多个模块。但是这样分成多个模块了，当我们进行项目打包发布的时候，那么要每一个模块都执行打包操作吗？这种重复的操作我们怎么才能避免呢？

创建一个聚合工程，将其他的各个模块都由这个聚合工程来管理，那么我们在进行项目发布的时候，只需要打包这个聚合工程就可以了。

第一步：创建聚合工程（注意聚合工程的打包方式也必须为 pom，通常由 上面所讲的父工程来充当聚合工程）

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.java.user</groupId>
  <artifactId>user-aggregator</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>pom</packaging>
  
  <modules>
  	<module>../user-dao</module>
  	<module>../user-service</module>
  </modules>
</project>

对user-dao和user-service模块进行统一管理

第二步：创建子工程：业务层

①、选择 Maven Module

②、填写子工程模块名，打包方式选择 jar（子工程除了 web 层我们打包方式选择 war ，其余的都选择 jar）

　第三步：创建子工程：表现层和持久层

　创建步骤和前面一样，注意表现层打包方式我们要选择 war，因为要发布到 tomcat 容器运行。

　第四步：在聚合工程中添加子工程的引用

<modules>
    <module>Service</module>
    <module>Controller</module>
    <module>Mapper</module>
  </modules>

注意：

　　1、这里虽然各个模块有依赖关系，但是 <module></modelu>可以不让依赖顺序添加，maven会自动识别依赖关系进行编译打包。

　　2、这里总的聚合工程随便哪个工程都可以，但是通常用 Parent 工程来完成。

构建web项目