为什么要使用maven 使用maven有什么好处

  1. maven不仅是构建工具，它还是依赖管理工具和项目管理工具，提供了中央仓库，能够帮我们自动下载构件。

    2.为了解决的依赖的增多，版本不一致，版本冲突，依赖臃肿等问题，它通过一个坐标系统来精确地定位每一个构件（artifact）。

    3.还能帮助我们分散在各个角落的项目信息，包括项目描述，开发者列表，版本控制系统，许可证，缺陷管理系统地址。

    4.maven还为全世界的Java开发者提供了一个免费的中央仓库，在其中几乎可以找到任何的流行开源软件。通过衍生工具(Nexus),我们还能对其进行快速搜索

    5.maven对于目录结构有要求，约定优于配置，用户在项目间切换就省去了学习成本。

对比,Maven,IDE,Mark,Ant
a.IDE:基本上所有的主流IDE都集成了Maven,我们可以在IDE中方便的运行Mave执行构建.IDE依赖大量的手工操作。编译、测试、代码生成等工作都是相互独立的，很难一键完成所有工作。手工劳动往往意味着低效，意味着容易出错很难在项目中统一所有的IDE配置，每个人都有自己的喜好。也正是由于这个原因，一个在机器A上可以成功运行的任务，到了机器B的IDE中可能就会失败。
所以,要合理使用IDE,不过多依赖.Maven是专家.

b.Make也许是最早的构建工具，具体不详,没用过,可以不了解.Make的强大之处在于它可以利用所有系统的本地命令，尤其是UNIX/Linux系统，丰富的功能、强大的命令能够帮助Make快速高效地完成任务。
但是，Make将自己和操作系统绑定在一起了。也就是说，使用Make，就不能实现（至少很难）跨平台的构建，这对于Java来说是非常不友好的。此外，Makefile的语法也成问题，很多人抱怨Make构建失败的原因往往是一个难以发现的空格或Tab使用错误。

c.Ant是意指“另一个整洁的工具”（Another Neat Tool），它最早用来构建著名的Tomcat，其作者James Duncan Davidson创作它的动机就是因为受不了Makefile的语法格式。我们可以将Ant看成是一个Java版本的Make，也正因为使用了Java，Ant是跨平台的。此外，Ant使用XML定义构建脚本，相对于Makefile来说，这也更加友好。
和Make一样，Ant也都是过程式的，开发者显式地指定每一个目标，以及完成该目标所需要执行的任务。针对每一个项目，开发者都需要重新编写这一过程，这里其实隐含着很大的重复。Maven是声明式的，项目构建过程和过程各个阶段所需的工作都由插件实现，并且大部分插件都是现成的，开发者只需要声明项目的基本元素，Maven就执行内置的、完整的构建过程。这在很大程度上消除了重复。
Ant是没有依赖管理的，所以很长一段时间Ant用户都不得不手工管理依赖，这是一个令人头疼的问题。幸运的是，Ant用户现在可以借助Ivy管理依赖。而对于Maven用户来说，依赖管理是理所当然的，Maven不仅内置了依赖管理，更有一个可能拥有全世界最多Java开源软件包的中央仓库，Maven用户无须进行任何配置就可以直接享用。

3.Maven与极限编程
极限编程（XP）是近些年在软件行业红得发紫的敏捷开发方法，它强调拥抱变化。
首先看一下Maven如何帮助XP团队实现一些核心价值：
?简单。Maven暴露了一组一致、简洁的操作接口，能帮助团队成员从原来的高度自定义的、复杂的构建系统中解脱出来，使用Maven现有的成熟的、稳定的组件也能简化构建系统的复杂度。
?交流与反馈。与版本控制系统结合后，所有人都能执行最新的构建并快速得到反馈。此外，自动生成的项目报告也能帮助成员了解项目的状态，促进团队的交流。

Maven几乎能够很好地支持任何软件开发方法。
例如，在传统的瀑布模型开发中，项目依次要经历需求开发、分析、设计、编码、测试和集成发布阶段。从设计和编码阶段开始，就可以使用Maven来建立项目的构建系统。在设计阶段，也完全可以针对设计开发测试用例，然后再编写代码来满足这些测试用例。然而，有了自动化构建系统，我们可以节省很多手动的测试时间。此外，尽早地使用构建系统集成团队的代码，对项目也是百利而无一害。最后，Maven还能帮助我们快速地发布项目

相信一提到Maven，大家脑海里浮现出来它的第一个作用，就是用来打包，但是经常“用完即走”的我们真的到了需要认认真真梳理一下Maven的相关概念了。

Maven为我们提供了一套自动化的构建方案，从最基础的清理、编译代码、运行测试到打包和部署。这一系列过程称之为它的生命周期。

file

默认情况下，Maven有三套相互独立的生命周期，分别是 clean、default 和site。每个生命周期包含一些阶段（phase），阶段是有顺序的，后面的阶段依赖于前面的阶段。每个阶段的内部由 插件的 Goals(目标）组成。

可以这样理解，其实phase就是goal的容器。真正被执行的都是goal （目标）。

phase （阶段）被执行时，实际执行的都是被绑定到该 phase （阶段）的一系列goal（目标）。

而 goal（目标） 与 goal （目标）之间是独立的。单独执行一个goal不会导致其他goal被执行。

深入理解 maven 的生命周期
maven使用一个名为 components.xml 的配置文件来描述其架构的组织结构，以我本地的maven 3.6.0版本为例。不同版本的maven， 配置文件的路径相似。

apache-maven-${version}\lib\maven-core-${version}.jar
\META-INFO\plexus\conponents.xml
这里我们针对default生命周期来作详细的了解：

file

下图是我整理出default生命周期的所有 phase (阶段)。

file

mvn { 例如: mvn package }
可以看到 当我们执行一个 简单的 mvn package 时，maven其实内部按照顺序流转了很多的phase (阶段)。

那如何来理解 Goal (目标）呢？

我们前面说过，一系列的 Goal （目标） 组成 了 phase (阶段)。

相信你用过maven的很多插件吧？这里我以 打 jar包的插件为例来介绍：

file

聪明的你看到这个图可能已经猜到了，jar：后面的一系列单词 就是Goal （目标）。

解释一下，goal 其实是由存在于Maven的插件plugin提供的一个个小的功能程序。你可以根据自己的实际需求，灵活的来组装他们，实现各种定制的功能。执行格式为：

mvn [插件名称]:[goal的名称]
再举一个实际案例，在打包时，分离出三方的依赖包。我们会使用到一个叫maven-dependency-plugin的插件。

file

上图表明，我制定了一个copy-dependencies 的目标，在 prepare-package 阶段执行。也就是在执行package打包之前，拷贝依赖到当前工程的lib文件夹下面。

直接通过执行命令也能达到上述的效果：

mvn clean dependency:copy-dependencies package
file

Maven 管理项目的依赖
Maven提供的依赖管理，是其中的一大核心功能。就像文章开始所说的，我们需要一个jar包，这个jar包又依赖于另外的jar包，这种依赖关系会不断的传递，直至最后一个没有任何其他依赖包。

Maven就是通过自动去发现和包含这些传递的依赖，避免了我们人工的去搜索下载。

这个传递依赖的层级是没有限制的，在使用过程中需要注意的一点是，循环依赖的问题。

file

遭遇到循环依赖如何解决呢？Maven 提供了一个 build-helper-maven-plugin 插件。其原理是： 将三个模块合并成一个中间的工程，临时编译出模块D，然后三个模块再分别依赖D 进行编译。

不推荐使用这种办法，这会导致我们的项目工程结构很混乱，只能作为临时规避的一个措施来使用。

还有一种办法是通过分析依赖，从根本上消除掉循环依赖。常用的分析依赖的命令有：

mvn dependency:help
mvn dependency:analyze
mvn dependency:tree
mvn dependency:tree -Dverbose
除了使用命令查看依赖树，常见的办法还有：

在项目启动时把所有的加载的 jar 包都打印出来，添加 VM 参数 -verbose:class 。通过打印的信息确认是否正确的 jar 包被依赖。
有的时候仅仅通过 mvn dependency:tree 可能无法快速的发现冲突，这个时候就可以尝试使用 Enforcer 插件，这个插件也可以自定义许多规则，我们可以使用 dependencyConvergence 规则。 来保证所有的依赖都使用相同的版本。



org.apache.maven.plugins
maven-enforcer-plugin
1.3.1


enforce




enforce






Maven 管理的依赖范围
依赖范围主要是用来限制各个包的传递性。并且影响我们最终的构建结果。 在引入依赖时，通过标签来指定依赖的范围。

file

Maven 内部为我们提供了 6种依赖的范围：

compile：缺省值，编译、测试都有效。
provided:编译，测试都有效，但是在运行时并不会加入。例如Servlet API，因为Web容器本身有，如果加入就会出现冲突。

runtime：测试、运行有效，表明这个依赖项不是编译所必须的，但是是执行时需要的。需要位于运行时的类路径中。

test：仅测试时有效，这个范围不是可传递的。

system：与本机相关，可移植性差。

import：导入的依赖范围，仅适用在dependencyManager中，表示从其他pom导入dependency配置。

dependencyManagement 作用
上面介绍的依赖范围都比较好理解，最后一个import范围涉及到一个dependencyManagement，这里我们具体解释一下他和dependencies 的区别。

dependencyManagement 主要有两个作用：

一是集中管理项目的依赖项
二是控制使用的依赖项的版本
1、 如果有多个子模块依赖相同的包，那么放在 中来管理。

使用 dependencyManagement 声明依赖，在项目中并不会实际引入，因此子项目需要显示声明需要用的依赖。

当不在子项目中声明依赖的时候，是不会从父项目中继承下来的。

只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且 version 和 scope 都读取自父 pom

如果子项目中指定了版本号，那么会使用子项目中指定的 jar 版本

而对于 dependencies ：

dependencies 即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项。父工程使用 dependencyManagement 假引用，目的是管理版本号。dependencies 用于实际上需要引入的工程，这些工程如果继承于父工程会找到对应的版本号。

Maven 的仓库分类
从大类来看，Maven仓库主要分为两大类，一是本地仓库，二是远程仓库。

本地仓库，主要是用来存储从远程仓库下载的插件和 jar 包，当项目需要使用 插件 或 jar 包时，会优先从本地仓库中查找。

远程仓库，是当无法在本地仓库中查找到包时，会默认去远程仓库下载。

远程仓库包括了，中央仓库、镜像仓库和私服。

file

而在配置了多个 Maven 仓库查找依赖的顺序大致如下：

1) 在本地仓库中寻找，如果没有则进入下一步。
2) 在全局配置的私服仓库（settings.xml中配置的并有激活）中寻找，如果没有则进入下一步。

3) 在项目自身配置的私服仓库（pom.xml）中寻找，如果没有则进入下一步。

4) 在中央仓库中寻找，如果没有则终止寻找。

http://www.cnblogs.com/hongwz/p/5456578.html

管理下载包，自定义版本包下载！