- 解决依赖冲突
- 引用变量的三种情况(maven命令)
- 多环境属性过滤
- 各种依赖(POM文件详解)
解决maven传递依赖中的版本冲突
传递依赖是maven最有特色的、最为方便的优点之一，可以省了很多配置。如a 依赖 b,b 依赖c 默认 a也会依赖 c。但是 也会带来隐患，如版本冲突。当然maven也考虑到解决办法，可以使用exclusions来排除相应的重复依赖。
但是我们还会遇到一个严重的问题，那就是，我怎么知道是哪个包的传递依赖产生的冲突 ？那该怎么办呢？当然，maven也会有相应的解决方案。
首先，你要在pom.xml中加上maven-project-info-reports-plugin插件。
maven-project-info-reports-plugin
然后再执行：mvn project-info-reports:dependencies 。生成项目依赖的报表，这样你就能够在报表中找出你版本冲突的相关性依赖了。
最后在相应的dependency中加上exclusions来排除相关的传递依赖。
例：
jaxen
jaxen
1.1.1
com.ibm.icu
icu4j
runtime
----------------------------------------------------------
maven中内置隐式变量的使用：
1、引用pom.xml的project下的标签元素
引用pom.xml的project根标签下的自标签
例如：${project.groupId}
${project.artifactId}
使用maven命令查看pom.xml的完整信息
1.${project.build.directory} 构建目录，缺省为target
2.${project.build.outputDirectory} 构建过程输出目录，缺省为target/classes
3.${project.build.finalName} 产出物名称，缺省为
${project.artifactId}-${project.version}
4.${project.packaging} 打包类型，缺省为jar
5.${project.xxx} 当前pom文件的任意节点的内容
6.${basedir} 项目根目录
maven命令
2、引用maven的settings.xml中的元素
(默认settings.xml的路径：~/.m2/settings.xml)
使用方式：
${settings.offline}会引用~/.m2/settings.xml文件中offline元素的值。
3、引用系统环境变量的属性
使用方式：${env.PATH}——会被操作系统中的环境变量替换
----------------------------------------------------------
profile和filtering实现多个环境下的属性过滤
1、配置文件：“test.properties”，里面随便来上一行，例如Hello ${user.name}
2、
src/main/resources
**/*.xsd
**/*.properties
true
3、编译我们的maven项目
$mvn clean compile -Duser.name=tom
查看输出文件 target/classes/test.properties 的内容，可见原先的
“Hello {user.name}” 已经变成 “Hello Tom”。
src/main/resources
**/*.xsd
**/*.properties
true
project.properties
profile功能：允许在项目文件（pom.xml）里面定义若干个profile段，然后在编译时选择
其中的一个用于覆盖项目文件原先的定义。
src/main/resources
**/*.xsd
**/*.properties
true
dev
true
pre.properties
pre
dev.properties
maven-war-plugin
2.5
在编译项目时，可以使用 -P 参数指定需要使用的 profile 的 id，比如下面命令将会使用
dev profile：$mvn clean compile -P dev
如果想使用pre，只需要改为以下即可
$mvn clean compile -Ppre
假如不指定 -P 参数的话，则会使用 activeByDefault=true 的一项（即 pre）。
----------------------------------------------------------
4.0.0
com.ali.aa
core
1.0.0-SNAPSHOT
jar
POM文件详解
joda-time
joda-time
2.3
java_Date与 Joda Time
commons类库详解
commons-io
commons-io
${commons-io.version}
Commons io--IOUtils
Commons之Commons-io
org.apache.commons
commons-lang3
${commons-lang3.version}
commons-lang3方法应用
commons-lang3工具类的学习
org.apache.httpcomponents
httpclient
4.5.2
httpcomponents介绍和使用
学习笔记1
学习笔记2
httpcomponents之httpclient发送http请求
org.apache.httpcomponents
httpclient
${httpclient.version}
commons-codec
commons-codec
commons codec基本使用
使用Commons codec 加密
Commons codec使用介绍
commons-collections
commons-collections
${commons-collections.version}
集合工具类的使用
commons-collections之Map
----------------------------------------------------------
build部分
lifecycle：生命周期，这是maven最高级别的的控制单元，它是一系列的phase组成，也就
是说，一个生命周期，就是一个大任务的总称，不管它里面分成多少个子任务，反正就是运
行一个lifecycle，就是交待了一个任务，运行完后，就得到了一个结果，中间的过程，是
phase完成的，自己可以定义自己的lifecycle，包含自己想要的phase
phase：可以理解为任务单元，lifecycle是总任务，phase就是总任务分出来的一个个子任
务，但是这些子任务是被规格化的，它可以同时被多个lifecycle所包含，一个lifecycle可
以包含任意个phase，phase的执行是按顺序的，一个phase可以绑定很多个goal，至少为一
个，没有goal的phase是没有意义的
goal: 这是执行任务的最小单元，它可以绑定到任意个phase中，一个phase有一个或多个
goal，goal也是按顺序执行的，一个phase被执行时，绑定到phase里的goal会按绑定的时
间被顺序执行，不管phase己经绑定了多少个goal，你自己定义的goal都可以继续绑到
phase中。
官方文档：
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.
html
http://maven.apache.org/ref/3.3.9/maven-core/lifecycles.html
mojo: lifecycle与phase与goal都是概念上的东西，mojo才是做具体事情的，可以简单理
解mojo为goal的实现类，它继承于AbstractMojo，有一个execute方法，goal等的定义都
是通过在mojo里定义一些注释的anotation来实现的，maven会在打包时，自动根据这些
anotation生成一些xml文件，放在plugin的jar包里
详情