- 解决依赖冲突
- 引用变量的三种情况(maven命令)
- 多环境属性过滤
- 各种依赖(POM文件详解)
解决maven传递依赖中的版本冲突
传递依赖是maven最有特色的、最为方便的优点之一，可以省了很多配置。如a 依赖 b,b 依赖c 默认 a也会依赖 c。但是 也会带来隐患，如版本冲突。当然maven也考虑到解决办法，可以使用exclusions来排除相应的重复依赖。
但是我们还会遇到一个严重的问题，那就是，我怎么知道是哪个包的传递依赖产生的冲突 ？那该怎么办呢？当然，maven也会有相应的解决方案。
首先，你要在pom.xml中加上maven-project-info-reports-plugin插件。
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>
maven-project-info-reports-plugin
</artifactId>
</plugin>
</reporting>
然后再执行：mvn project-info-reports:dependencies 。生成项目依赖的报表，这样你就能够在报表中找出你版本冲突的相关性依赖了。
最后在相应的dependency中加上exclusions来排除相关的传递依赖。
例：
<dependency>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
<version>1.1.1</version>
<exclusions>
<exclusion>
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
</exclusion>
</exclusions>
<scope>runtime</scope>
</dependency>
----------------------------------------------------------
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}——会被操作系统中的环境变量替换
----------------------------------------------------------
1、配置文件：“test.properties”，里面随便来上一行，例如Hello ${user.name}
2、<build>
<!--第一种方式，两种方式都需要指定需要编译的目录 -->
<resources>
<resource>
<directory>src/main/resources</directory>
<!--可以在此配置过滤文件 -->
<includes>
<include>**/*.xsd</include>
<include>**/*.properties</include>
</includes>
<!--开启filtering功能 -->
<filtering>true</filtering>
</resource>
</resources>
<build>
3、编译我们的maven项目
$mvn clean compile -Duser.name=tom
查看输出文件 target/classes/test.properties 的内容，可见原先的
“Hello {user.name}” 已经变成 “Hello Tom”。
<build>
<!--第二种方式，两种方式都需要指定需要编译的目录 -->
<resources>
<resource>
<directory>src/main/resources</directory>
<!--可以在此配置过滤文件 -->
<includes>
<include>**/*.xsd</include>
<include>**/*.properties</include>
</includes>
<!--开启filtering功能 -->
<filtering>true</filtering>
</resource>
</resources>
<filters>
<!-- 是以该pom文件路径作为参考 -->
<filter>project.properties</filter>
</filters>
<build>
profile功能：允许在项目文件（pom.xml）里面定义若干个profile段，然后在编译时选择
其中的一个用于覆盖项目文件原先的定义。
<build>
<!--第一种方式，两种方式都需要指定需要编译的目录 -->
<resources>
<resource>
<directory>src/main/resources</directory>
<!--可以在此配置过滤文件 -->
<includes>
<include>**/*.xsd</include>
<include>**/*.properties</include>
</includes>
<!--开启filtering功能 -->
<filtering>true</filtering>
</resource>
</resources>
<profiles>
<profile>
<id>dev</id>
<activation>
<!--默认的编译选项 -->
<activeByDefault>true</activeByDefault>
</activation>
<build>
<filters>
<filter>pre.properties</filter>
</filters>
</build>
</profile>
<profile>
<id>pre</id>
<build>
<filters>
<filter>dev.properties</filter>
</filters>
</build>
</profile>
</profiles>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<version>2.5</version>
</configuration>
</plugin>
</plugins>
</build>
在编译项目时，可以使用 -P 参数指定需要使用的 profile 的 id，比如下面命令将会使用
dev profile：$mvn clean compile -P dev
如果想使用pre，只需要改为以下即可
$mvn clean compile -Ppre
假如不指定 -P 参数的话，则会使用 activeByDefault=true 的一项（即 pre）。
----------------------------------------------------------
<modelVersion>4.0.0</modelVersion>
<!-- 模型版本。maven2.0必须是这样写，现在是maven2唯一支持的版本 -->
<groupId>com.ali.aa</groupId>
<!-- 公司或者组织的唯一标志，并且配置时生成的路径也是由此生成， 如com.ali.aa，
maven会将该项目打成的jar包放本地路径：/com/ali/aa -->
<artifactId>core</artifactId>
<!-- 本项目的唯一ID，一个groupId下面可能多个项目，就是靠artifactId来区分的 -->
<version>1.0.0-SNAPSHOT</version>
<!-- 本项目目前所处的版本号 -->
<packaging>jar</packaging>
<!-- 打包的机制，如pom,jar, maven-plugin, ejb, war, ear, rar, par，
默认为jar -->
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.3</version>
</dependency>
commons类库详解
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>${commons-io.version}</version>
</dependency>
Commons io--IOUtils
Commons之Commons-io
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>${commons-lang3.version}</version>
</dependency>
commons-lang3方法应用
commons-lang3工具类的学习
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
httpcomponents介绍和使用
学习笔记1
学习笔记2
httpcomponents之httpclient发送http请求
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>${httpclient.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
</exclusions>
</dependency>
commons codec基本使用
使用Commons codec 加密
Commons codec使用介绍
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>${commons-collections.version}</version>
</dependency>
集合工具类的使用
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包里
