Maven
次要内容
Maven的简介
简介
Maven【[mevn]】这个词能够翻译为"专家",“外行”。 作为Apache组织中的一个颇为胜利的开源我的项目，Maven次要服务于基于java平台的我的项目构建，依赖治理和我的项目信息管理。
无论是小型的开源类库我的项目，还是大型的企业级利用； 无论是传统的瀑布式开发，还是风行的麻利开发，Maven都能大显神通。
我的项目构建
不论你是否意识到，构建（build）是每一位程序员每天都在做的工作。早上来到公司，咱们做的第一件事就是从源码库签出最新的代码，而后进行单元测试，如果测试失败，会找相干的共事一起调试，修复错误代码。 接着回到本人的工作上来，编写本人的单元测试及产品代码。
认真总结一下，咱们会发现，除了编写源代码，咱们每天有相当一部分工夫花在了编译，运行单元测试，生成文档，打包和部署等繁琐且不起眼的工作上，这就是构建。 如果咱们当初还手工这样做，那老本也太高了，于是有人用软件的办法让这一系列工作齐全自动化，使得软件的构建能够像全自动流水线一样，只须要一条简略的命令，所有繁琐的步骤都可能主动实现，很快就能失去最终后果。
我的项目构建工具
Ant构建
最早的构建工具，基于IDE, 大略是2000年有的，过后是最风行java构建工具，不过它的XML脚本编写格局让XML文件特地大。对工程构建过程中的过程管制特地好
Maven【JAVA】
我的项目对象模型，通过其形容信息来治理我的项目的构建，报告和文档的软件项目管理工具。它填补了Ant毛病，Maven第一次反对了从网络上下载的性能，依然采纳xml作为配置文件格式。Maven专一的是依赖治理，应用Java编写。
**Gradle** 属于联合以上两个的长处，它继承了Ant的灵便和Maven的生命周期治理，它最初被google作为了Android御用管理工具。它最大的区别是不必XML作为配置文件格式，采纳了DSL格局，使得脚本更加简洁。
目前市面上Ant比拟老，所以个别是一些比拟传统的软件企业公司应用，Maven应用Java编写， 是当下大多数互联网公司会应用的一个构建工具， 中文文档也比拟齐全, gradle是用groovy编写，目前比拟新型的构建工具一些初创互联网公司会应用，当前会有很大的应用空间。
Maven的四大个性
依赖管理系统
Maven为Java世界引入了一个新的依赖管理系统jar包治理 jar 降级时批改配置文件即可。在Java世界中，能够用groupId、artifactId、version组成的Coordination（坐标）惟一标识一个依赖。
任何基于Maven构建的我的项目本身也必须定义这三项属性，生成的包能够是Jar包，也能够是war包或者jar包。一个典型的依赖援用如下所示：
<dependency> <groupId>javax.servlet</groupId> com.baidu <artifactId>javax.servlet-api</artifactId> ueditor echarts <version>3.1.0</version></dependency> 坐标属性的了解
Maven坐标为各种组件引入了秩序，任何一个组件都必须明确定义本人的坐标。
groupId
定义以后Maven我的项目附属的理论我的项目-公司名称。（jar包所在仓库门路） 因为Maven中模块的概念，因而一个理论我的项目往往会被划分为很多模块。 比方spring是一个理论我的项目，其对应的Maven模块会有很多，如spring-core,spring-webmvc等。
artifactId
该元素定义理论我的项目中的一个Maven模块-我的项目名， 举荐的做法是应用理论项目名称作为artifactId的前缀。 比方： spring-bean、 spring-webmvc等。
version
该元素定义Maven我的项目以后所处的版本。
多模块构建
我的项目复查时 dao service controller 层拆散将一个我的项目合成为多个模块曾经是很通用的一种形式。
在Maven中须要定义一个parent POM作为一组module的聚合POM。在该POM中能够应用 标签来定义一组子模块。parent POM不会有什么理论构建产出。而parent POM中的build配置以及依赖配置都会主动继承给子module。
统一的我的项目构造
Ant时代大家创立Java我的项目目录时比拟随便，而后通过Ant配置指定哪些属于source，那些属于testSource等。而Maven在设计之初的理念就是Conversion over configuration（约定大于配置）。其制订了一套我的项目目录构造作为规范的Java我的项目构造,解决不同ide 带来的文件目录不统一问题。
统一的构建模型和插件机制
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.25</version> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <contextPath>/test</contextPath> </configuration></plugin> Maven的装置配置和目录构造
Maven的装置配置
查看JDK的版本
JDK版本1.7及以上版本
下载Maven
下载地址：http://maven.apache.org/downl...
配置Maven环境变量
解压后把Maven的根目录配置到零碎环境变量中MAVEN_HOME，将bin目录配置到path变量中。
注：maven解压后寄存的目录不要蕴含中文和空格
查看Maven是否装置胜利
关上dos窗口，执行 mvn -v
意识Maven目录构造
Maven我的项目目录构造
工作:手动创立一个Maven我的项目，并编译运行胜利！
创立一个文件夹作为我的项目的根目录
在根目录中创立一个pom.xml文件，内容如下
<?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/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.xxxx</groupId> <artifactId>maven01</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>maven01</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> Ps：标签定义解释
根目录下的第一个子元素 ModelVersion指定以后Pom模型的版本，对于Maven3来说，它只能是4.0.0 。指定了以后Maven模型的版本号，对于Maven2和Maven3来说，它只能是4.0.0groupId定义了我的项目属于哪个组， 这个组往往和我的项目所在的组织和公司存在关联。 比方： com.xxxxartifactId 定义了以后Maven我的项目在组中惟一的ID。Version X.X.X-里程碑比方：1.0.0-SNAPSHOT 第一个X 大版本 有重大改革第二个X 小版本 修复bug，减少性能第三个X 更新里程碑版本： SNAPSHOT （快照，开发版）alpha（内部测试）beta（公开测试）Release | RC（ 公布版）GA（失常版本）应用name标签申明一个对于用户更为敌对的项目名称，尽管不是必须的，但还是举荐为每个Pom申明name，以不便信息交换。 编写主函数
package com.xxxx.demo;public class Hello{ public static void main(String[] args) { System.out.println("hello maven"); }} cmd 下编译并运行
cmd上面，进入我的项目的根目录
1. 编译java文件
mvn compile
2. 执行main 办法
mvn exec:java -Dexec.mainClass=“com.xxxx.demo.Hello”
注：第一次下载会比较慢，要批改maven解压之后的conf目录下的settings.xml。
1.1.批改默认仓库地位关上maven目录 -> conf -> settings.xml增加仓库地位配置<localRepository>F:/m2/repository</localRepository>注：仓库地位改为本人本机的指定目录，"/"不要写反1.2.更换阿里镜像,放慢依赖下载<mirror> <id>nexus-aliyun</id> <mirrorOf>central</mirrorOf> <name>Nexus aliyun</name> <url>http://maven.aliyun.com/nexus/content/groups/public</url></mirror> 如果编译不胜利，可能呈现的问题
1. 不是应用管理员权限执行dos命令2. JDK环境配置有问题，重装JDK3. 代码编写时，类外面没设置包名（如果编译时类没加包名，执行时也不须要加包名） Maven命令
作为开发利器的maven，为咱们提供了非常丰盛的命令，理解maven的命令行操作并纯熟使用常见的maven命令还是十分必要的，即便譬如IDEA等工具给我提供了图形界面化工具，但其底层还是依附maven命令来驱动的。
Maven的命令格局如下：
mvn [plugin-name]:[goal-name] 命令代表的含意：执行plugin-name插件的goal-name指标
常用命令
命令
形容
mvn –version
显示版本信息
mvn clean
清理我的项目生产的临时文件,个别是模块下的target目录
mvn compile
编译源代码，个别编译模块下的src/main/java目录
mvn package
我的项目打包工具,会在模块下的target目录生成jar或war等文件
mvn test
测试命令,或执行src/test/java/下junit的测试用例.
mvn install
将打包的jar/war文件复制到你的本地仓库中,供其余模块应用
mvn deploy
将打包的文件公布到近程参考,提供其余人员进行下载依赖
mvn site
生成我的项目相干信息的网站
mvn eclipse:eclipse
将我的项目转化为Eclipse我的项目
mvn dependency:tree
打印出我的项目的整个依赖树
mvn archetype:generate
创立Maven的一般java我的项目
mvn tomcat7:run
在tomcat容器中运行web利用
mvn jetty:run
调用 Jetty 插件的 Run 指标在 Jetty Servlet 容器中启动 web 利用
留神：运行maven命令的时候，首先须要定位到maven我的项目的目录，也就是我的项目的pom.xml文件所在的目录。否则，必以通过参数来指定我的项目的目录。 命令参数
下面列举的只是比拟通用的命令，其实很多命令都能够携带参数以执行更精准的工作。
-D 传入属性参数
例如：mvn package -Dmaven.test.skip=true
以-D结尾，将maven.test.skip的值设为true,就是通知maven打包的时候跳过单元测试。同理，mvn deploy-Dmaven.test.skip=true代表部署我的项目并跳过单元测试。
-P 应用指定的Profile配置
比方我的项目开发须要有多个环境，个别为开发，测试，预发，正式4个环境，在pom.xml中的配置如下：
<profiles> <profile> <id>dev</id> <properties> <env>dev</env> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>qa</id> <properties> <env>qa</env> </properties> </profile> <profile> <id>pre</id> <properties> <env>pre</env> </properties> </profile> <profile> <id>prod</id> <properties> <env>prod</env> </properties> </profile></profiles> ...... <build> <filters> <filter>config/${env}.properties</filter> </filters> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> ...... </build> profiles定义了各个环境的变量id，filters中定义了变量配置文件的地址，其中地址中的环境变量就是下面profile中定义的值，resources中是定义哪些目录下的文件会被配置文件中定义的变量替换。
通过maven能够实现按不同环境进行打包部署，例如：
mvn package -Pdev -Dmaven.test.skip=true
示意打包本地环境，并跳过单元测试
IDEA编辑器集成Maven环境
设置Maven版本
抉择 “File” —> “Other Settings” —> “Settings for New Projects…” —> 搜寻 “Maven”
抉择下载好的maven版本（目录选到bin目录的上一级目录）
设置settings.xml文件
设置好之后，抉择 “Apply” 或者 “OK”
Maven我的项目的创立
创立 Java我的项目
新建我的项目
- 抉择 “File” —> “New” —> “Project”
- 抉择"Maven"，设置JDK版本，抉择maven我的项目的模板
- 设置我的项目的 GroupId 和 ArtifactId
- 查看Maven环境，抉择 “Next”
- 查看我的项目名和工作空间，抉择 “Finish”
- 期待我的项目创立，下载资源，创立实现后目录构造如下
注：右下角弹出的提示框，抉择 “Enable Auto-Import”（Maven启动主动导入）
编译我的项目
- 点击右上角的 "Add Configurations "，关上 “Run/Debug Configurations” 窗口
- 点击左上角的 “+” 号，抉择 “Maven”
- 设置编译我的项目的命令
- 执行编译命令，两个图标别离代表"一般模式"和"调试模式"
- 编译胜利
创立 Web我的项目
创立我的项目
- 创立Web我的项目与创立Java我的项目步骤基本一致，区别在于抉择 Maven模板（web项目选择webapp），如图：
注：其余步骤与创立一般的Java我的项目雷同。 - 我的项目目录构造如下：
启动我的项目
批改 JDK 的版本
<!-- JDN的版本批改为1.8 --><properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target></properties> 设置单元测试的版本
<!-- junit的版本批改为4.12 --><dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency></dependencies> 删除pluginManagement标签
<!-- 将这个标签及标签中的内容全副删除 --><pluginManagement>...</pluginManagement> 增加web部署的插件
在 build 标签中增加 plugins 标签
Jetty插件
<!-- 设置在plugins标签中 --><plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.25</version> <configuration> <!-- 热部署，每10秒扫描一次 --> <scanIntervalSeconds>10</scanIntervalSeconds> <!-- 可指定以后我的项目的站点名 --> <contextPath>/test</contextPath> <connectors> <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector"> <port>9090</port> <!-- 设置启动的端口号 --> </connector> </connectors> </configuration></plugin>Tomcat插件
<!-- 设置在plugins标签中 --><plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.1</version> <configuration> <port>8081</port> <!-- 启动端口 默认:8080 --> <path>/test</path> <!-- 我的项目的站点名，即对外拜访门路 --> <uriEncoding>UTF-8</uriEncoding> <!-- 字符集编码 默认：ISO-8859-1 --> <server>tomcat7</server> <!-- 服务器名称 --> </configuration></plugin>
启动我的项目
- 点击右上角的 "Add Configurations "，关上 “Run/Debug Configurations” 窗口
- 点击左上角的 “+” 号，抉择 “Maven”
Jetty插件配置
也能够输出命令指定端口启动
jetty:run -Djetty.port=9090 # 须要将插件配置中的port标签去掉点击启动图标，启动服务
启动胜利
浏览器拜访成果- Tomcat插件配置
启动形式如上，启动胜利
浏览器拜访 http://localhost:8080/test
- Maven依赖仓库：
https://mvnrepository.com/
- Tomcat7插件的命令：
https://tomcat.apache.org/mav...
Maven仓库的基本概念
当第一次运行Maven命令的时候， 你须要Internet链接， 因为它须要从网上下载一些文件。 那么它从哪里下载呢？ 它是从Maven默认的近程库下载的。 这个近程仓库有Maven的外围插件和可供下载的jar文件。
对于Maven来说， 仓库只分为两类： 本地仓库和近程仓库。
当Maven依据坐标寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在，则间接应用； 如果本地没有，Maven就会去近程仓库查找，发现须要的构件之后，下载到本地仓库再应用。 如果本地仓库和近程仓库都没有，Maven就会报错。
近程仓库分为三种： 地方仓库，私服， 其余公共库。
地方仓库是默认配置下，Maven下载jar包的中央。
私服是另一种非凡的近程仓库，为了节俭带宽和工夫，应该在局域网内架设一个公有的仓库服务器，用其代理所有内部的近程仓库。 外部的我的项目还能部署到私服上供其余我的项目应用。
一般来说，在Maven我的项目目录下，没有诸如lib/这样用来寄存依赖文件的目录。 当Maven在执行编译或测试时，如果须要应用依赖文件，它总是基于坐标应用本地仓库的依赖文件。
默认状况下， 每个用户在本人的用户目录下都有一个路径名为.m2/repository/的仓库目录。 有时候，因为某些起因（比方c盘空间有余）,须要批改本地仓库目录地址。
对于仓库门路的批改，能够通过maven 配置文件conf 目录下settings.xml来指定仓库门路
<!-- 设置到指定目录中，门路的斜杆不要写反 --><settings> <localRepository>D:/m2/repository</localRepository></settings> 地方仓库
因为原始的本地仓库是空的，maven必须晓得至多一个可用的近程仓库，能力执行maven命令的时候下载到须要的构件。地方仓库就是这样一个默认的近程仓库。
maven-model-builder-3.3.9.jar maven主动的 jar 中蕴含了一个 超级POM。定义了默认地方仓库的地位。
地方仓库蕴含了2000多个开源我的项目，接管每天1亿次以上的拜访。
私服
私服是一种非凡的近程仓库，它是架设在局域网内的仓库服务， 私服代理广域网上的近程仓库，供局域网内的maven用户应用。 当maven须要下载构件时， 它去私服当中找，如果私服没有， 则从内部近程仓库下载，并缓存在私服上， 再为maven提供。
此外，一些无奈从内部仓库下载的构件也能从本地上传到私服提供局域网中其他人应用
配置形式我的项目pom.xml 配置
<repositories> <repository> <snapshots> <enabled>true</enabled> </snapshots> <id>public</id> <name>Public Repositories</name> <url>http://192.168.0.96:8081/content/groups/public/</url> </repository> <repository> <id>getui-nexus</id> <url>http://mvn.gt.igexin.com/nexus/content/repositories/releases/</url> </repository></repositories> 公司外部应该建设私服：
- 节俭本人的外网带宽
- 减速maven构建
- 部署第三方控件
- 进步稳定性
- 升高地方仓库的负荷
其余公共库
罕用的阿里云仓库配置
<mirror> <id>nexus-aliyun</id> <mirrorOf>central</mirrorOf> <name>Nexus aliyun</name> <url>http://maven.aliyun.com/nexus/content/groups/public</url></mirror> Maven环境下构建多模块我的项目
应用maven 提供的多模块构建的个性实现maven 环境下多个模块的我的项目的治理与构建。
这里以四个模块为例来搭建我的项目,以达到通俗易懂的初衷 模块 maven_parent —– 基模块,就是常说的parent （pom）模块 maven_dao —– 数据库的拜访层，例如jdbc操作（jar）模块 maven_service —– 我的项目的业务逻辑层 （jar）模块 maven_controller —– 用来接管申请，响应数据 （war） 创立 maven_parent 我的项目
- 抉择 File —> Settings —> Project
- 设置 GroupId 和 ArtifactId
- 设置项目名称及工作空间
创立 maven_dao 模块
- 抉择我的项目maven_parent，右键抉择 New ，抉择Module
- 抉择Maven我的项目的模板（一般 Java 我的项目）
- 设置子模块的的 ArtifactId
- 设置Maven的配置
- 设置子模块的名称及寄存地位
创立 maven_service 模块
创立 maven_service 模块的步骤与 maven_dao模块统一。
建 maven_controller 模块
创立 maven_service 模块的步骤与 maven_dao模块基本一致，只须要将第一步抉择Maven模板设置为web我的项目即可。（模板类型：maven-archetype-webapp）
模块全副创立结束后，成果如下：
批改模块的配置
- 设置 JDK 版本
- 单元测试 JUnit版本
- 删除多余的配置
设置模块之间的依赖
maven_dao
- 新建包
- 在包中创立 UserDao类
在类中增加办法
package com.xxxx.dao;public class UserDao { public static void testDao() { System.out.println("UserDao Test..."); }}
maven_service
增加maven_dao的依赖
<!-- 退出maven_dao模块的依赖 --><dependency> <groupId>com.xxxx</groupId> <artifactId>maven_dao</artifactId> <version>1.0-SNAPSHOT</version></dependency>在我的项目中增加UserService类，并增加办法
package com.xxxx.service;import com.xxxx.dao.UserDao;public class UserService { public static void testService() { System.out.println("UserService Test..."); // 调用UserDao的办法 UserDao.testDao(); }}
maven_controller
增加 maven_service 模块的依赖
<!-- 退出maven_service模块的依赖 --><dependency> <groupId>com.xxxx</groupId> <artifactId>maven_service</artifactId> <version>1.0-SNAPSHOT</version></dependency>增加Servlet的依赖
<!-- Servlet的依赖 --><dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.0.1</version> <scope>provided</scope></dependency>新建 Java 类，继承 HttpServlet 类，并重写 service办法
package com.xxxx.controller;import com.xxxx.service.UserService;import javax.servlet.ServletException;import javax.servlet.annotation.WebServlet;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import java.io.IOException;@WebServlet("/user")public class UserServlet extends HttpServlet { @Override protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.out.println("UserServlet Test..."); // 调用UserService层的办法 UserService.testService(); }}增加Tomcat插件
<!-- 增加插件 --><plugins> <!-- tomcat7插件 --> <plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.1</version> <configuration> <!-- <port>8080</port> --> <path>/web</path> <uriEncoding>UTF-8</uriEncoding> <server>tomcat7</server> </configuration> </plugin></plugins>- 启动我的项目
- 拜访我的项目
拜访地址：
http://localhost:8080/web/user拜访后果：
- 如果启动失败，请先将父我的项目 install
注：如果父我的项目 install 失败，则先将所有子模块 install 胜利后，再 install 父我的项目。
Maven的打包操作
对于企业级我的项目，无论是进行本地测试，还是测试环境测试以及最终的我的项目上线，都会波及我的项目的打包操作。对于每个环境下的我的项目打包，对应的我的项目所须要的配置资源都会有所区别，实现打包的形式有很多种，能够通过ant，或者通过idea 自带的打包性能实现我的项目打包，但当我的项目很大并且须要的外界配置很多时，此时打包的配置就会异样简单，对于maven 我的项目，咱们能够用过 pom.xml 配置的形式来实现打包时的环境抉择，相比拟其余模式打包工具，通过maven 只须要通过简略的配置，就能够轻松实现不同环境下我的项目的整体打包。
比方上面这样一个我的项目，我的项目中配置了不同环境下我的项目所须要的配置文件，这时候须要实现不同环境下的打包操作，此时通过批改pom.xml 如下：
建设对应的目录构造
应用idea创立我的项目，目录构造可能会缺失，须要通过手动增加对应的目录。
- 增加 Java 源文件夹
抉择我的项目的 main 文件夹，右键抉择New，抉择Directory
输出文件夹名 “Java”，如图：
抉择 java 目录，右键抉择 Mark Directory as，抉择 Sources Root。将文件夹标记为源文件夹。
- 增加资源文件夹
步骤如上，创立文件夹，命名为 resources，并标记为 Resources Root
- 增加对应的文件夹目录，及增加不同环境下对应的配置文件。（本地环境、测试环境、正式环境）
增加Profile配置
<!-- 打包环境配置 开发环境 测试环境 正式环境 --><profiles> <profile> <id>dev</id> <properties> <env>dev</env> </properties> <!-- 未指定环境时，默认打包dev环境 --> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>test</id> <properties> <env>test</env> </properties> </profile> <profile> <id>product</id> <properties> <env>product</env> </properties> </profile></profiles> 设置资源文件配置
<!-- 对于我的项目资源文件的配置放在build中 --><resources> <resource> <directory>src/main/resources/${env}</directory> </resource> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> <include>**/*.properties</include> <include>**/*.tld</include> </includes> <filtering>false</filtering> </resource></resources> 执行打包操作
关上Run/Debug Configuarations窗口，输出对应的打包命令
此时对应打包命令
1. `clean compile package -Dmaven.test.skip=true` 打包默认环境（开发环境）并且跳过maven 测试操作
2. `clean compile package -Ptest -Dmaven.test.skip=true` 打包测试环境并且跳过maven 测试操作
3. `clean compile package -Pproduct -Dmaven.test.skip=true` 打包生产环境并且跳过maven 测试操作
打包胜利
不同的我的项目打包的文件不一样，一般来说，一般java我的项目打成jar包，web我的项目打成war包
Maven依赖的基本概念
依赖的根本配置
根元素project下的dependencies能够蕴含多个 dependence元素，以申明多个依赖。每个依赖都应该蕴含以下元素：
- groupId, artifactId, version : 依赖的根本坐标， 对于任何一个依赖来说，根本坐标是最重要的， Maven依据坐标能力找到须要的依赖。
- Type： 依赖的类型，大部分状况下不须要申明。 默认值为jar
Scope： 依赖范畴（compile,test,provided,runtime,system）
- compile: 编译依赖范畴。
如果没有指定，就会默认应用该依赖范畴。应用此依赖范畴的Maven依赖，对于编译、测试、运行三种classpath都无效。
- test: 测试依赖范畴。
应用此依赖范畴的Maven依赖，只对于测试classpath无效，在编译主代码或者运行我的项目的应用时将无奈应用此类依赖。典型的例子就是JUnit，它只有在编译测试代码及运行测试的时候才须要。
- provided: 已提供依赖范畴。
应用此依赖范畴的Maven依赖，对于编译和测试classpath无效，但在运行时有效。典型的例子是servlet-api，编译和测试项目的时候须要该依赖，但在运行我的项目的时候，因为容器曾经提供，就不须要Maven反复地引入一遍(如：servlet-api)。
- runtime: 运行时依赖范畴。
应用此依赖范畴的Maven依赖，对于测试和运行classpath无效，但在编译主代码时有效。典型的例子是JDBC驱动实现，我的项目主代码的编译只须要JDK提供的JDBC接口，只有在执行测试或者运行我的项目的时候才须要实现上述接口的具体JDBC驱动。
- system: 零碎依赖范畴。
该依赖与三种classpath的关系，和provided依赖范畴完全一致。然而，应用system范畴依赖时必须通过systemPath元素显式地指定依赖文件的门路。因为此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因而应该审慎应用。
- compile: 编译依赖范畴。
- Optional：标记依赖是否可选
- Exclusions： 用来排除传递性依赖。
依赖范畴
首先须要晓得，Maven在编译我的项目主代码的时候须要应用一套classpath。 比方：编译我的项目代码的时候须要用到spring-core, 该文件以依赖的形式被引入到classpath中。 其次， Maven在执行测试的时候会应用另外一套classpath。 如：junit。
最初在理论运行我的项目时，又会应用一套classpath， spring-core须要在该classpath中，而junit不须要。
那么依赖范畴就是用来管制依赖与这三种classpath(编译classpath，测试classpath，运行时classpath)的关系， Maven有以下几种依赖范畴：
- Compile 编译依赖范畴。 如果没有指定，就会默认应用该依赖范畴。 应用此依赖范畴的Maven依赖， 对于编译，测试，运行都无效。
- Test： 测试依赖范畴。 只在测试的时候须要。比方junit
- Provided： 已提供依赖范畴。 应用此依赖范畴的Maven依赖，对于编译和测试无效， 但在运行时有效。 典型的例子是servlet-API, 编译和测试项目的须要， 但在运行我的项目时， 因为容器曾经提供， 就不须要Maven反复地引入一遍。
- Runtime： 运行时依赖范畴。 应用此依赖范畴的Maven依赖，对于测试和运行无效， 但在编译代码时有效。 典型的例子是：jdbc驱动程序， 我的项目主代码的编译只须要jdk提供的jdbc接口，只有在执行测试或者运行我的项目的时候才须要实现上述接口的具体jdbc驱动。
- System： 零碎依赖范畴。 个别不应用。
传递性依赖
传递依赖机制， 让咱们在应用某个jar的时候就不必去思考它依赖了什么。也不必放心引入多余的依赖。 Maven会解析各个间接依赖的POM，将那些必要的间接依赖，以传递性依赖的模式引入到以后我的项目中。
留神： 传递依赖有可能产生抵触！！
抵触场景：
A-->B--->C (2.0)A-->E--->C (1.0) 如果A下同时存在两个不同version的C，抵触！！（选取同时适宜A、B的版本）
<dependencies> <dependency> <groupId>A</groupId> <artifactId>A</artifactId> <version>xxx</version> <exclusions> <exclusion> <groupId>C</groupId> <artifactId>C</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>B</groupId> <artifactId>B</artifactId> </dependency> </dependencies>