《Maven权威指南》学习笔记(三)

构建生命周期

Maven使用POM描述项目，将其建模成一些名词.在Maven中这些“动词”是由Maven插件包装的一些目标，它们绑定到一个构建生命周期的阶段中.当你让Maven构建一个项目的时候，你其实是让它一步步通过那些预定义的有序的阶段，并且运行所有注册到某个特定阶段的目标

Maven中有三种标准的生命周期：清理（clean），默认（default）(有时候也称为构建)，和站点（site）

清理生命周期 (clean):它包含了三个生命周期阶段pre-clean,clean,post-clean

简单的运行clean:clean目标不会完整的执行该生命周期，但是指定clean阶段就能使用clean生命周期，并且逐个的经过生命周期阶段，直到到达clean阶段(可能未到post-clean阶段就停了)
指定post-clean阶段能经过完整的clean生命周期,直到post-clean阶段.
直接运行pre-clean阶段会提示:[INFO] No goals needed for project – skipping.可以在它的构建配置中，绑定了某个目标至pre-clean阶段
可以自定义Clean插件的行为去删除构建输出目录以外的文件

默认生命周期 (default):它是一个软件应用程序构建过程的总体模型。第一个阶段是validate，最后一个阶段是deploy
站点生命周期 (site):它包含了四个阶段：1. pre-site 2. site 3. post-site 4. site-deploy 默认绑定到站点生命周期的目标是：1. site – site:site 2. site-deploy -site:deploy
在上述这些生命周期里,如果某个生命周期阶段没有目标绑定在其上,运行该阶段会提示[INFO] No goals needed for project – skipping



打包相关生命周期

绑定到每个阶段的特定目标默认根据项目的打包类型设置

JAR打包默认的目标
生命周期阶段 目标
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package jar:jar
install install:install
deploy deploy:deploy

通用生命周期目标

Process Resources:

大部分生命周期将resources:resources目标绑定到process-resources阶段.。process-resources阶段处理资源并将资源复制到输出目录,同时也会在资源上应用过滤器，能让你替换资源文件中的一些符号(而不是指pom.xml)
要配置使用该default.properties文件的资源过滤，我们需要在这个项目的POM中指定两样东西：构建配置的filters元素中的属性文件列表，以及一个标记告诉Maven资源目录需要过滤。默认的Maven行为会跳过过滤，只是将资源复制到输出目录；你需要显式的配置资源过滤，否则Maven就会置之不理
添加资源目录列表<resource> <directory>src/main/images</directory> </resource>
也可以声明两个资源目录，给它们提供不同的过滤配置和目标目录配置

Compile:

大部分生命周期将Compiler插件的compile目标绑定到compile阶段
可以为Compiler插件设置source和target版本
如果你想要存储项目的源码至src/java而非src/main/java，让构建输出至classes而非target/classes，你可以覆盖定义在超级POM中的sourceDirectory的默认值

Process Test Resources: 调用resources:testResources
Test Compile:调用compile:testCompile编译测试源代码目录至测试构建构建输出目录
Test:大部分生命周期绑定Surefire插件的test目标至test阶段

maven.test.skip变量同时控制Compiler和Surefire插件，如果你传入maven.test.skip，就等于告诉Maven整个的跳过测试

Install:Install插件的install目标基本上都是绑定到install生命周期阶段。install:install目标只不过是将项目的主要构件安装到本地仓库,如果这个项目的打包类型是POM，那么该目标就仅仅复制POM到本地仓库
Deploy:Deploy插件的deploy目标通常绑定到deploy生命周期阶段。该阶段用来将一个构件部署到远程Maven仓库，当你执行一次发布的时候通常需要更新远程仓库

第11章 构建Profile 和 第12章 Maven套件 先跳过不看(profile能解决产品环境和开发环境数据库地址不同的问题)
属性和资源过滤

属性

你可以在pom.xml文件或者资源文件中使用属性，资源文件被会Maven Resource插件的过滤特性处理
隐式的属性:project.*,settings.*env.*,Java系统属性
Maven项目的属性:

任何在Maven POM 中的东西都可以用属性来引用(project.groupId 和 project.version)

如果你试图在Maven中引用输出目录，你绝不应该使用如target/classes的字面量，而是应该使用属性来引用这些目录(project.build.*)

关于Maven Model对象可用属性的完整列表(关于model对象的属性还不是很清楚,应该是诸如model.*)

Maven的Settings属性
环境变量属性
Java系统属性:任何你能从System.getProperty()获取的属性都能以Maven属性的形式引用,如:java.version
用户定义的属性:

用户定义的属性可以在POM中引用，也可以由Maven Resource插件用来过滤资源

资源过滤:

你可以使用Maven来对项目资源进行变量替换。在资源过滤被激活的时候，Maven会扫描资源，寻找由${ 和}包围的Maven属性的引用。一旦它找到这些引用，它就会使用合适的值去替换它们，就像前一节中定义的属性可以在POM中引用一样
该节和profile有点关联,因为第11章未看,理解不够深.

第 14 章 Maven和Eclipse: m2eclipse 没有IDE,跳过
第15章及其以后的章节都先跳过.
附录A稍微过了一遍.附录B没看.

要点:

Maven 不知道如何打包 WAR 文件，也不知道如何运行单元测试，Maven大部分的智能是由插件实现的，而插件从 Maven 仓库获得.当你下载Maven的时候，你得到的是一个包含了基本躯壳的Maven核心，它知道如何解析命令行，管理classpath，解析POM文件，在需要的时候下载Maven插件
conf/ 目录包含了一个全局的settings.xml文件，该文件用来自定义你机器上Maven的一些行为。如果你需要自定义Maven，更通常的做法是覆写~/.m2目录下的settings.xml文件，每个用户都有对应的这个目录

当Maven运行一个目标的时候，每个目标都会访问定义在项目POM里的信息

在一个Java项目中，Java类放在src/main/java下面，而classpath资源文件放在src/main/resources下面
Maven自带了一个用来下载Maven核心插件和依赖的远程仓库地址（http://repo1.maven.org/maven2）
Maven仓库的标准是按照下面的目录格式来存储构件，相对于仓库的根目录：/<groupId>/<artifactId>/<version>/<artifactId>-<version>.<packaging>
一旦Maven已经从远程仓库下载了一个构件，它将永远不需要再下载一次，因为maven会首先在本地仓库查找插件，然后才是其它地方
它支持了传递性依赖（transitive dependencies）,Maven会隐式的把这些库间接依赖的库也加入到你的项目中.
添加一些关于项目许可证，组织以及项目相关开发人员的一些信息.，licenses，organization 和 developers 等元素
一个插件目标也被认为是一个 “Mojo”

开启调试输出允许你看到Maven 工作时的依赖机制,查看完整的依赖踪迹: mvn install -X

PS:

学习如何浏览邮件列表
artifact:人工制品;手工艺品;加工品
archetype:原型
snapshot:快照

问题:

在向create目标传入了packageName参数,与不传入没什么区别,生成的pom.xml没有变化,最后打包的名称也没有不同.
一开始构建前将conf/setting.xml下的repository地址改过后,将不会生成默认的~/.m2文件夹,而且针对每个用户的配置文件~/.m2/setting.xml也没有生成.