<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.2</version>
    </dependency>
    ...
  <dependencies>
</dependencyManagement>Copy to clipboardErrorCopied

<dependencies>
  <dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
  </dependency>
</dependencies>Copy to clipboardErrorCopied

<dependencyManagement>
     <dependencies>
        <dependency>
            <!-- Import dependency management from Spring Boot -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>1.3.0.RC1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>Copy to clipboardErrorCopied

• compile，缺省值，适用于所有阶段，会随着项目一起发布。compile 是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围。编译范围依赖在所有的 classpath 中可用，同时它们也会被打包。
• provided，provided 依赖只有在当 JDK 或者一个容器已提供该依赖之后才使用。例如，如果你开发了一个 Web 应用，你可能在编译 classpath 中需要可用的 ServletAPI 来编译一个 servlet，但是你不会想要在打包好的 WAR 中包含这个 ServletAPI；这个 Servlet API JAR 由你的应用服务器或者 servlet 容器提供。已提供范围的依赖在编译 classpath(不是运行时)可用。它们不是传递性的，也不会被打包。
• runtime，runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要 JDBC API JAR，而只有在运行的时候才需要 JDBC 驱动实现。
• test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
• system，system 范围依赖与 provided 类似，但是你必须显式的提供一个对于本地系统中 JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的(你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖)。

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>javax.sql</groupId>
      <artifactId>jdbc-stdext</artifactId>
      <version>2.0</version>
      <scope>system</scope>
      <systemPath>${java.home}/lib/rt.jar</systemPath>
    </dependency>
  </dependencies>
  ...
</project>Copy to clipboardErrorCopied

<dependency>
  <groupId>dnsns</groupId>
  <artifactId>dnsns</artifactId>
  <version>1.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/lib/dnsns.jar</systemPath>
</dependency>
<dependency>
  <groupId>localedata</groupId>
  <artifactId>localedata</artifactId>
  <version>1.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/lib/localedata.jar</systemPath>
</dependency>
<dependency>
  <groupId>sunjce_provider</groupId>
  <artifactId>sunjce_provider</artifactId>
  <version>1.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/lib/sunjce_provider.jar</systemPath>
</dependency>
<dependency>
  <groupId>sunpkcs11</groupId>
  <artifactId>sunpkcs11</artifactId>
  <version>1.0</version>
  <scope>system</scope>
  <systemPath>${project.basedir}/src/lib/sunpkcs11.jar</systemPath>
</dependency>Copy to clipboardErrorCopied

• install:install 即默认的 maven install 执行的命令，用来自动地将本项目的主 artifact 以及它的附件如 source，doc 安装到本地的仓库中。
• install:install-file 作为 install 的补充，安装你指定的文件到本地仓库。
• install:help 本插件的帮助信息。

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>**</version>

• compile（默认使用）：编译依赖范围，编译、测试、运行都生效；
• test：测试依赖范围，只在测试的 classpath 有效，比如我们常用的 JUnit；
• provided：只对编译和测试有效，对运行无效，常用于容器提供了的运行环境；
• runtime：运行时依赖范围，比如 JDBC 驱动，编译和测试时不需要，只需要使用 JDK 提供的 JDBC 接口；
• system：系统依赖范围，依赖 Maven 仓库以外的依赖。

• 第一原则：路径最短优先选中，将 pom 文件默认为一个树形结构，路径节点从根出发。
  • 假设：路径 1 是：A->B->C->D(version1.0)，路径 2 是：A->B->D(version2.0)。由于路径 2 的长度小于路径 1，所以结果就是 A 会传递性依赖 D(version2.0)，当路径长度相等的时候，使用第二原则
• 第二原则：先声明者优先原则
  • 当路径长度相同时候，就要使用第二原则。假设：路径 1 不变依然是：A->B->C->D(version1.0)，路径 2 是：A->B->E->D(version2.0)，由于路径 1 在路径 2 前面声明，所以结果就是 A 会传递性依赖 D(version1.0)。
• 第三原则：冲突 jar 句柄顺序随机原则
  • 如果系统自己已经在 target 目录中加载了有冲突的 jar 包，并且机器有一定概率可以启动成功，主要是当打包的时候包会打印到 target 目录中，编译机器和目标机器执行了打包上传解压，在这个过程中就会引起互相冲突的 jar 在目标机器上排序，系统启动的时候，加载包的顺序就是随机的。

• 启动时直接报错，java.lang.ClassNotFoundException ,或者方法不存在：这种比较简单，直接查找该类在哪个包中，相互冲突的基本上在两个 jar 包内就可以确定，基本手段：排除低版本，选择和自己 Java 代码一致使用的，排除和业务代码无关的。
• 类路径长度统计，版本就高不就低。这点需要找到有疑似冲突的，做一个简单的统计，常常新版本的会解决之前的问题，但是也有一个潜在的风险，高版本的可能引入了更多有可能的冲突，因此，高版本的尽量遵循业务无关的类库，如果和业务有关，尽量把两个版本的依赖树都保存以做比对，或者和具体业务负责人确认改动点。
• 隐含错误加上调试参数：mvn +X dependency:tree>tree.log，这样根据报错信息可以更精确的定位到错误或者冲突。

• M2HOME: 指向 Maven 安装目录
• Path: 追加 Maven 安装目录下的 bin 目录

# 查看maven版本
mvn -v
# 编译
mvn compile
# 测试
mvn test
# 打包
mvn package
# 删除 target
mvn clean
# 安装jar包到本地仓库中
mvn install
# 创建一个新工程
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false
Copy to clipboardErrorCopied

<mirror>
  <id>CN</id>
  <name>OSChina Central</name>
  <url>http://maven.oschina.net/content/groups/public/</url>
  <mirrorOf>central</mirrorOf>
</mirror>Copy to clipboardErrorCopied

<settings>
  ...
    <proxies>
        <proxy>
            <id>my-proxy</id>
            <active>true</active>
            <protocol>http</protocol>
            <host>代理服务器主机名</host>
            <port>端口号</port>
            <!--
                <username>***</username>
                <password>***</password>
                <nonProxyHosts>repository.mycom.com|*.google.com</nonProxyHosts>
            -->
        </proxy>
    </proxies>
  ...
</settings>Copy to clipboardErrorCopied

• 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 中。
• mojo: lifecycle 与 phase 与 goal 都是概念上的东西，mojo 才是做具体事情的，可以简单理解 mojo 为 goal 的实现类，它继承于 AbstractMojo，有一个 execute 方法，goal 等的定义都是通过在 mojo 里定义一些注释的 anotation 来实现的，maven 会在打包时，自动根据这些 anotation 生成一些 XML 文件，放在 plugin 的 jar 包里。

• clean 生命周期：清理项目，包含三个 phase：
  • pre-clean：执行清理前需要完成的工作
  • clean：清理上一次构建生成的文件
  • post-clean：执行清理后需要完成的工作
• default 生命周期：构建项目，重要的 phase 如下：
  • validate：验证工程是否正确，所有需要的资源是否可用。
  • compile：编译项目的源代码。
  • test：使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。
  • package：把已编译的代码打包成可发布的格式，比如 jar。
  • integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境。
  • verify：运行所有检查，验证包是否有效且达到质量标准。
  • install：把包安装到 maven 本地仓库，可以被其他工程作为依赖来使用。
  • deploy：在集成或者发布环境下执行，将最终版本的包拷贝到远程的 repository，使得其他的开发者或者工程可以共享。
• site 生命周期：建立和发布项目站点，phase 如下：
  • pre-site：生成项目站点之前需要完成的工作
  • site：生成项目站点文档
  • post-site：生成项目站点之后需要完成的工作
  • site-deploy：将项目站点发布到服务器

• mvn clean：调用 clean 生命周期的 clean 阶段，实际执行 pre-clean 和 clean 阶段
• mvn test：调用 default 生命周期的 test 阶段，实际执行 test 以及之前所有阶段
• mvn clean install：调用 clean 生命周期的 clean 阶段和 default 的 install 阶段，实际执行 pre-clean 和 clean，install 以及之前所有阶段

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.wx.mvn</groupId>
  <artifactId>hello-world</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>Maven Hello World Project</name>
</project>Copy to clipboardErrorCopied

• 代码的第一行是 XML 头，指定了该 XML 文档的版本和编码方式。紧接着是 project 元素，project 是所有 pom.xml 的根元素，它还声明了一些 POM 相关的命名空间及 xsd 元素，虽然这些属性不是必须的，但使用这些属性能够让第三方工具(如 IDE 中的 XML 编辑器)帮助我们快速编辑 POM。
• 根元素下的第一个子元素 modelVersion 指定了当前 POM 模型的版本，对于 Maven 2 及 Maven 3 来说，它只能是 4.0.0。这段代码中最重要的是 groupId，artifactId 和 version 三行。这三个元素定义了一个项目基本的坐标，在 Maven 的世界，任何的 jar、pom 或者 war 都是以基于这些基本的坐标进行区分的。
• groupId 定义了项目属于哪个组，这个组往往和项目所在的组织或公司存在关联，譬如你在 googlecode 上建立了一个名为 myapp 的项目，那么 groupId 就应该是 com.googlecode.myapp，如果你的公司是 mycom，有一个项目为 myapp，那么 groupId 就应该是 com.mycom.myapp。
• artifactId 定义了当前 Maven 项目在组中唯一的 ID，我们为这个 Hello World 项目定义 artifactId 为 hello-world，本书其他章节代码会被分配其他的 artifactId。而在前面的 groupId 为 com.googlecode.myapp 的例子中，你可能会为不同的子项目(模块)分配 artifactId，如：myapp-util、myapp-domain、myapp-web 等等。
• version 指定了 Hello World 项目当前的版本——1.0-SNAPSHOT。SNAPSHOT 意为快照，说明该项目还处于开发中，是不稳定的版本。随着项目的发展，version 会不断更新，如升级为 1.0、1.1-SNAPSHOT、1.1、2.0 等等。
• 最后一个 name 元素声明了一个对于用户更为友好的项目名称，虽然这不是必须的，但我还是推荐为每个 POM 声明 name，以方便信息交流。没有任何实际的 Java 代码，我们就能够定义一个 Maven 项目的 POM，这体现了 Maven 的一大优点，它能让项目对象模型最大程度地与实际代码相独立，我们可以称之为解耦，或者正交性，这在很大程度上避免了 Java 代码和 POM 代码的相互影响。比如当项目需要升级版本时，只需要修改 POM，而不需要更改 Java 代码；而在 POM 稳定之后，日常的 Java 代码开发工作基本不涉及 POM 的修改。

<properties>
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 <spring.version>1.2.6</spring.version>
 <developer.organization><![CDATA[xy公司]]></developer.organization>
</properties>Copy to clipboardErrorCopied

<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-core</artifactId>
 <version>${spring.version}</version>
</dependency>
<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-aop</artifactId>
 <version>${spring.version}</version>
</dependency>Copy to clipboardErrorCopied

package com.wx.mvn.helloworld;
public class HelloWorld {
  public String sayHello() {
    return "Hello Maven";
  }
  public static void main(String[] args) {
    System.out.print(new HelloWorld().sayHello());
  }
}Copy to clipboardErrorCopied

maven-metadata.xml
maven-metadata.xml.md5
maven-metadata.xml.sha1Copy to clipboardErrorCopied

<?xml version="1.0" encoding="UTF-8"?>
<metadata modelVersion="1.1.0">
  <groupId>io.github.hengyunabc</groupId>
  <artifactId>mybatis-ehcache-spring</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <versioning>
    <snapshot>
      <timestamp>20150804.095005</timestamp>
      <buildNumber>1</buildNumber>
    </snapshot>
    <lastUpdated>20150804095005</lastUpdated>
  </versioning>
</metadata>Copy to clipboardErrorCopied

<repositories>
  <repository>
    <id>hengyunabc-maven-repo</id>
    <url>file:/home/hengyunabc/code/maven-repo/repository/</url>
  </repository>
</repositories>