在如今的互联网项目开发当中，特别是Java领域，Maven的仓库管理、依赖管理、继承和聚合等特性为项目的构建提供了一整套完善的解决方案。
这里我们通过7个关于Maven的提问来了解Maven的一些基本知识。
Maven的一般使用方式
在进行提问之前，先了解下Maven的一般使用方式。
一般在搭建开发环境的时候（使用Maven做项目管理），你安装完JDK后就会安装配置Maven（MAVEN_HOME、path），很大可能性你需要修改settings.xml文件，比如你会修改本地仓库地址路径，比如你很可能会copy一段配置到你的settings.xml中（很可能就是私服的一些配置）。
接下来，你会到IDEA或者Eclipse中进行Maven插件配置，然后你就可以在工程中的pom.xml里面开始添加<dependency>标签来管理jar包，在Maven规范的目录结构下进行编写代码，最后你就可以通过插件的方式来进行测试、打包（jar or war）、部署、运行。
提问1：什么是Maven的本地仓库？Maven到底有哪些仓库？这些仓库之间有什么关系？
Maven查找jar包是先到本地仓库查找，如果在本地仓库找不到，就上私服去找，在私服上也找不到，就到中央仓库去查找。如果最后在中央仓库找到了，就会在私服和本地仓库都放一份，以便下次不用去中央仓库去找，因为中央仓库是需要消耗网络资源的。
在上面的描述中就可以得到Maven中的仓库有三个，一个是本地仓库，一个是私服，一个是中央仓库。
本地仓库顾名思义就是在你的本地建立的仓库，本地仓库就是相当于加了一层jar包缓存。
私服，就是公司内部局域网的一台服务器而已，你想一下，当你的工程Project-A依赖别人的Project-B的接口，怎么做呢？没有Maven的时候，当然是copy Project-B jar到你的本地lib中引入，那么Maven的方式，很显然需要其他人把Project-B deploy到私服仓库中供你使用。因此私服中存储了本公司的内部专用的jar！不仅如此，私服还充当了中央仓库的镜像。
中央仓库，存储了互联网上的jar，由Maven团队来维护，地址是：http://repo1.maven.org/maven2/。
提问2：对于<dependency>标签的使用你了解多少？
这里以commons-dbcp作为例子。
上图是pom.xml文件中使用作为<dependency>标签引入依赖的实例，下面我们来看看下载下来在本地仓库是什么样子的。
可以看出，<dependency>标签揭示了jar的查找坐标的三个元素：groupId、artifactId和version。一般而言，我们可以到私服上输入artifactId进行搜索，或者到【http://search.maven.org/】、【http://mvnrepository.com/】上进行查找并确定坐标。
其中，version分为开发版本（Snapshot）和发布版本（Release），那么为什么要分呢？在实际开发中，我们经常遇到这样的场景，比如A服务依赖于B服务，A和B同时开发，B在开发中发现了BUG，修改后，将版本由1.0升级为2.0，那么A必须也跟着在POM.XML中进行版本升级。过了几天后，B又发现了问题，进行修改后升级版本发布，然后通知A进行升级。。。可以说这是开发过程中的版本不稳定导致了这样的问题。因此Maven替我们想好的解决方案就是使用Snapshot版本：在开发过程中B发布的版本标志为Snapshot版本，A进行依赖的时候选择Snapshot版本，那么每次B发布的话，会在私服仓库中，形成带有时间戳的Snapshot版本，而A构建的时候会自动下载B最新时间戳的Snapshot版本。
提问3：既然Maven进行了依赖管理，为什么还会出现依赖冲突？处理依赖冲突的手段是什么？
我们来看一个引用了两个不同版本的相同依赖的例子：
首先，对于Maven来说，在同一个groupId的同一个artifactId下，只能使用一个version，因为xml是从上至下依次解析的，因此写在后面的依赖会覆盖掉前面相同的依赖，于是根据依赖顺序就可以得出最终使用的版本是1.2版本的jar。
那么，我们可以思考关于依赖冲突的问题了。比如工程中需要引入A、B，而A依赖1.0版本的C，B依赖2.0版本的C，那么问题来了，因为C使用的版本将由引入A、B的顺序而定，如果A的依赖写在B的依赖后面，将意味着最后引入的是1.0版本的C，很可能在运行阶段出现类（ClassNotFoundException）、方法（NoSuchMethodError）找不到的错误（因为B使用的是高版本的C）。
事实上，这里涉及到了两个重要的概念，一个是传递依赖（Transitive），一个是Maven的最近依赖策略。传递依赖是指，如果A依赖B，B依赖于C，那么一旦引入了A就意味着B和C都会被引入。Maven的最近依赖策略是指，如果一个项目依赖相同的groupId、artifactId的多个版本，那么在依赖树（mvn dependency:tree）中离项目最近的那个版本将会被使用。
处理依赖冲突主要有以下三种做法：
1.如果我们清楚要使用哪个版本的话，就可以强制忽略传递依赖，进行版本锁定。具体的做法是使用<dependencyManagement>标签，这种做法主要用于子模块的版本一致性中。
2.在传递依赖中去掉不需要的或冲突的依赖。具体的做法是使用<exclusions>标签。
3.因为Maven有最近依赖策略，那么我们只要显式依赖指定的版本，就可以做到依赖覆盖的效果。具体的做法就是使用<dependency>标签将冲突的依赖选择一个合适的版本显式引入进来。
提问4：怎样提前发现依赖冲突的问题呢？
在工程中，我们避免不了需要加一些依赖，一般我们的做法都是在加了依赖后，实际运行时才会发现存在依赖冲突，然后再去解决依赖冲突的问题。那么能不能在运行前提前发现问题呢？答案是可以的，具体的做法是在新加入依赖之后使用mvn dependency:tree命令形成依赖树，就可以看出新加入的依赖是否存在传递依赖，传递依赖中是否和依赖树中的版本存在冲突。
提问5：Maven规范化的目录结构是怎样的？
我们都知道，Maven是遵循的【约定优于配置】理念的，因此其目录结构是规范化的。
上图是一个简单的Java工程的目录结构，有两点注意事项：
1.src/main下内容最终会打包到jar/war中，而src/test下是测试内容，并不会打包进去。
2.src/main/resources中的资源文件会copy至目标目录，这是Maven的默认生命周期中的一个规定动作。（可是这样的话，hibernate/mybatis的映射xml岂不是必须要放入resources下，而不能在放在其他地方了？实际上Maven提供了配置标签来包含其他目录下的资源文件）
提问6：Maven的生命周期是怎样的？
关于Maven的生命周期我们可以通过Idea开发工具中的Maven插件来了解。
当执行后面的命令时，前面的命令会自动得到执行，而实际上，我们最常用的就是这么几个：
clean：清理，将之前本地打包的东西清理掉。
compile：编译，编译代码。
package：打成jar包或ar包，会自动进行clean+compile。
install：将本地工程Jar上传到本地仓库。
deploy：上传到私服。
提问7：Maven中scope的依赖范围是怎样的？
既然，Maven的生命周期存在编译、测试、运行这些过程，那么显然有些依赖只用于测试，比如junit；有些依赖编译用不到，只有运行的时候才能用到，比如mysql的驱动包在编译期就用不到（编译期用的是JDBC接口），而是在运行时用到的；还有些依赖，编译期要用到，而运行期不需要提供，因为有些容器已经提供了，比如servlet-api在tomcat中已经提供了，我们只需要的是编译期提供而已。
compile：默认的scope，运行期有效，需要打入包中。
provided：编译期有效，运行期不需要提供，不会打入包中。
runtime：编译不需要，在运行期有效，需要导入包中（接口与实现分离）。
test：测试需要，不会打入包中。
system：非本地仓库引入、存在系统的某个路径下的jar（一般不使用）。
"衣带渐宽终不悔，为伊消得人憔悴。"