关于maven

晚上为了学习maven的插件扩展机制，搜索了跟maven相关的不少东西，将一些好的摘录一下：

InfoQ有幸采访到国内唯一的Sonotype（Maven背后的公司）员工许晓斌先生（ 百度搜索现在上阿里技术专家），请他谈谈关于Maven 3以及他即将出版的新书《Maven实战》
我从07年开始接触Maven，慢慢学习并在实际项目中推广使用，然后慢慢喜欢上了这个技术。1年之后我开始编写Maven中文博客并翻译《Maven权威指南》，并且维护了一个Google Group，我想这些事情对于Maven在国内的推广起到了一定的作用。也正是由于这些工作的关系，我有机会熟悉Maven的方方面面，并加入了Sonatype —— Maven之父Jason Van Zyl创建的公司。

采用Guice作为DI容器最大好处在于标准化，Maven之前使用的Plexus历史也很久，但发展得很差，文档也很缺乏，转到Guice后，由于大家更熟悉，就可以吸引更多的贡献者。Maven团队也不再需要花时间去维护，有了问题，可以得到Guice社区的帮助。

Maven 3在采用Guice的同时还必须支持Plexus风格DI标注或XML配置，以兼容现有的数以百计的Maven插件。为此Maven团队基于Guice 2.0所支持的自定义注入器，开发了一个中间层模块，该模块包含一个匹配器来识别你的标注配置是Plexus风格还是Guice支持的JSR300风格，如果是Plexus风格则再应用额外的集成逻辑。实现的细节在这两篇博客中有介绍：The Guice/Plexus Bridge and Custom Bean Injection，Create a Guice Bean Extension Layer。

下面是知乎及其他网友的摘录

Maven这个单词来自于意第绪语（犹太语），意为知识的积累，最初在Jakata Turbine项目中用来简化构建过程。
Maven是apache的一个顶级项目，它的出现越来越影响着现在的众多的开源项目，不仅如此，很多公司的很多新项目都采用Maven提倡的方式进行管理。Maven正逐渐侵入我们原先的管理项目的习惯，对于团队的管理，项目的构建，都是一种质的飞跃。
链接：https://www.zhihu.com/question/20104186/answer/87286506

Maven是通过采用各种模式来创建的一个具有可视性、复用性、可维护性和完整性等特征的基础设施。这么说有点太高大上了，接地气一点来说吧：Maven希望把软件开发中的一些最佳实践和模式都整合和固化下来，这样使用Maven来进行开发时，开发过程更爽，生产出来的软件更棒，具有以上所罗列的各种特性。这几种特性对于一个团队一起高效的开发协作的确是非常重要的。Maven最初的诞生就是希望Apache的一些项目能够以相同的方式来开发和构建，这样一个开发者从一个项目转到另外一个项目工作的时候能够更加轻松地切换。因为项目的开发、测试、文档生成、报表和部署，都具有一些共同的特征，这些特征就可以认为是软件开发过程中的一些最佳实践，当这些最佳实践成为共识，开发的协作必然会更加高效。那么Maven要做的就是把这些最佳实践固化成一个通用的项目管理方法。尽管对于不同的项目，开发中各个阶段会有所不同，但是确实可以找到一条普遍适用的路径，Maven将这条路径以非常清晰的方式结合各种实践模式提供给开发者。至于模式，学术上一般简单定义为针对一种类型的特性问题的解决方案。小到一个项目的目录模式(比如：代码放到哪？测试代码放到哪？资源放到哪？)，再大粒度一些比如项目的依赖如何管理，再大到整个项目构建的生命周期模式（比如：通用的构建过程包含哪些阶段？），都是Maven这个基础设施要提供给大家的，是Maven强制大家形成共同的认知。这样大家就能更快速地生产出棒棒哒的软件。

 

1 maven管理的目标：工程（Project）

 

maven是一个软件工程（Software Project）管理工具。 对于maven来说，一个软件工程的唯一标识是由开发者（groupId)、生成物（artifactId)、版本（version） 共同决定的。

每个工程都有一个打包类型，可以是jar, war, ear 或 pom。打包类型决定了工程最终产物的类型。 其中pom类型用于构件多模块工程。

工程之间有两种关系：依赖和聚合。

1.1 工程依赖关系

依赖关系的管理是maven最为人称道的地方。一个工程可以依赖多个其他工程， 通过工程的唯一标识（groupId+artifactId+version)可以明确指明依赖的库及版本，而且能够处理 依赖关系的传递。 maven可以指定依赖的作用范围（scope），包括以下几种：

scope	编译期	测试期	运行期	说明
*compile	V	V	V	默认scope
test		V		只在测试期依赖，如junit包
provided	V	V		运行期由容器提供，如servlet-api包
runtime		V	V	编译期间不需要直接引用
system	V	V		编译和测试时由本机环境提供

由于依赖关系的传递性可能会导致依赖的版本、scope等发生冲突，maven提供了仲裁机制，同时也 允许自己通过配置进行依赖管理。

1.2 工程聚合关系

前面提到pom类型用于于构件多模块工程，这体现了project之间的一种聚合关系： 将一系列小的模块聚合成整个产品。

通过聚合后的工程可以同时管理每个相关模块的构建、清理、文档等工作。 聚合关系通过在子工程中指定一个pom类型的project作为父project来定义。

2 maven的核心：生命周期和阶段

maven将工程（Project）的构建过程理解为不同的生命周期(LifeCycle)和阶段（Phase）。 在工程的构建过程中，存在着不同的生命周期，这些生命周期互相独立，之间也没有一定的顺序关系。 每个生命周期又划分为不同的阶段（Phase）。阶段之间有明确的顺序关系， 同一生命周期内的阶段必须按顺序依次执行。

maven内置了三个生命周期，并为每个生命周期内置了一些阶段。 下面列举出maven内置的生命周期及主要的阶段： 

• default：构建（Build）
  1. validate：验证项目是否正确，所有必需的信息是否可用。
  2. compile：编译项目中的代码。
  3. test：用相关的单元测试框架测试编译后的代码，这些运行的测试并不会随项目打包和布署。
  4. package：将编译后的代码打包成相应的格式文件，如jar包。
  5. integration-test： 如果需要在一个综合环境中运行我们的测试，这个阶段将会运行和布署项目到该环境中。
  6. verify： 检查项目的包是否正确和符合要求。
  7. install：将包安装到本地maven仓库，可以让其他项目作为依赖使用该包。
  8. deploy：将包发布到远程的maven仓库，并提供给其他开发者使用。
• clean：清理
  1. pre-clean 准备清理
  2. clean 执行清理工作
  3. post-clean 执行清理后的后续工作
• site：生成项目文档和站点
  1. pre-site 准备生成
  2. site 生成项目站点和文档
  3. post-site 执行生成文档后的后续工作
  4. site-deploy 发布项目文档

更详细的phase说明参考： http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

3 功能实现：插件和Goal

Maven中定义的工程周期和阶段只是抽象的概念，不涉及具体的功能。 具体的功能由插件（Plugin）实现。一个插件可以实现多个目标（Goal）。

为了解耦插件的功能和工程阶段，实现高度的可配置性，maven规定插件只是实现目标的功能， 通过配置来决定在哪个阶段执行（Execution)哪些目标操作。 甚至可以把一个Goal绑定到多个Phase，以实现复用。

maven内置了一些默认的插件，并根据不同的工程packing类型在各个phase中默认绑定了一些goal。 下表中列出default生命周期中各阶段默认绑定的goal，其中goal按照管理使用plugin_name:goal_{name的方式标记：}

Pahse	Plugin:Goal
process-resources	resources:resources
compile	compiler:compile
process-test-resources	resources:testResources
test-compile	compiler:testCompile
test	surefire:test
package	ejb:ejb/ejb3:ejb3/jar:jar/par:par/rar:rar/war:war
install	install:install
deploy	deploy:deploy

最后需要说明的是，maven的插件是一种packaging类型为maven-plugin的project， 可以使用maven project的依赖，配置插件等等一切特性。

4 仓库（Repository)

仓库主要用于获取工程依赖的其他工程的生成物，也可用来部署（deploy）maven工程的生成物。 生成物包括各种打包的生成物以及pom文件。

如果有必要，一个工程可以部署到多个仓库。

仓库可以分为本地库（local）和远程库（remote）。本地库通常位于本机的~/.m2/repository文件夹， 远程库最常见的是maven中央库（），此外也会有一些私服库用于企业内部。

http://www.cnblogs.com/holbrook/archive/2012/12/24/2830519.html