Maven入门教程

时间 2019-11-20

标签 maven 入门教程栏目 Maven 繁體版

原文原文链接

概念

Maven是什么

Maven 是一个项目管理工具。它负责管理项目开发过程当中的几乎全部的东西。html

版本java

maven有本身的版本定义和规则git

构建github

maven支持许多种的应用程序类型，对于每一种支持的应用程序类型都定义好了一组构建规则和工具集。web

输出物管理算法

maven能够管理项目构建的产物，并将其加入到用户库中。这个功能能够用于项目组和其余部门之间的交付行为apache

依赖关系浏览器

maven对依赖关系的特性进行细致的分析和划分，避免开发过程当中的依赖混乱和相互污染行为tomcat

文档和构建结果并发

maven的site命令支持各类文档信息的发布，包括构建过程的各类输出，javadoc，产品文档等。

项目关系

一个大型的项目一般有几个小项目或者模块组成，用maven能够很方便地管理

移植性管理

maven能够针对不一样的开发场景，输出不一样种类的输出结果

Maven的生命周期

maven把项目的构建划分为不一样的生命周期(lifecycle)。粗略一点的话，它这个过程(phase)包括：编译、测试、打包、集成测试、验证、部署。maven中全部的执行动做(goal)都须要指明本身在这个过程当中的执行位置，而后maven执行的时候，就依照过程的发展依次调用这些goal进行各类处理。

这个也是maven的一个基本调度机制。通常来讲，位置稍后的过程都会依赖于以前的过程。固然，maven一样提供了配置文件，能够依照用户要求，跳过某些阶段。

Maven的标准工程结构

Maven的标准工程结构以下：

|-- pom.xml(maven的核心配置文件)

|-- src

|-- main

| `-- java(java源代码目录)

| `-- resources(资源文件目录)

|-- test

`-- java(单元测试代码目录)

|-- target(输出目录，全部的输出物都存放在这个目录下)

|--classes(编译后的class文件存放处)

Maven的"约定优于配置"

所谓的"约定优于配置"，在maven中并非彻底不能够修改的，他们只是一些配置的默认值而已。可是除非必要，并不须要去修改那些约定内容。maven默认的文件存放结构以下：

每个阶段的任务都知道怎么正确完成本身的工做，好比compile任务就知道从src/main/java下编译全部的java文件，并把它的输出class文件存放到target/classes中。

对maven来讲，采用"约定优于配置"的策略能够减小修改配置的工做量，也能够下降学习成本，更重要的是，给项目引入了统一的规范。

Maven的版本规范

maven使用以下几个要素来惟必定位某一个输出物：

groudId

团体、组织的标识符。团体标识的约定是，它以建立这个项目的组织名称的逆向域名(reverse domain name)开头。通常对应着JAVA的包的结构。例如org.apache

artifactId

单独项目的惟一标识符。好比咱们的tomcat, commons等。不要在artifactId中包含点号(.)。

version

一个项目的特定版本。

packaging

项目的类型，默认是jar，描述了项目打包后的输出。类型为jar的项目产生一个JAR文件，类型为war的项目产生一个web应用。

maven有本身的版本规范，通常是以下定义 <major version>.<minor version>.<incremental version>-<qualifier> ，好比1.2.3-beta-01。要说明的是，maven本身判断版本的算法是major,minor,incremental部分用数字比较，qualifier部分用字符串比较，因此要当心 alpha-2和alpha-15的比较关系，最好用 alpha-02的格式。

maven在版本管理时候可使用几个特殊的字符串 SNAPSHOT，LATEST，RELEASE。好比"1.0-SNAPSHOT"。各个部分的含义和处理逻辑以下说明：

SNAPSHOT

这个版本通常用于开发过程当中，表示不稳定的版本。

LATEST

指某个特定构件的最新发布，这个发布多是一个发布版，也多是一个snapshot版，具体看哪一个时间最后。

RELEASE

指最后一个发布版。

安装

官网下载地址

http://maven.apache.org/download.cgi

配置环境变量

注意：安装maven以前，必须先确保你的机器中已经安装了JDK。

1．解压压缩包（以apache-maven-3.3.9-bin.zip为例）

2．添加环境变量MAVEN_HOME，值为apache-maven-3.3.9的安装路径

3．在Path环境变量的变量值末尾添加%MAVEN_HOME%\bin

4．在cmd输入mvn –version，若是出现maven的版本信息，说明配置成功。

本地仓储配置

从中央仓库下载的jar包，都会统一存放到本地仓库中。咱们须要配置本地仓库的位置。

打开maven安装目录，打开conf目录下的setting.xml文件。

能够参照下图配置本地仓储位置。

第一个Maven工程

在Eclipse中建立Maven工程

Maven插件

在Eclipse中建立Maven工程，须要安装Maven插件。

通常较新版本的Eclipse都会带有Maven插件，若是你的Eclipse中已经有Maven插件，能够跳过这一步骤。

点击Help -> Eclipse Marketplace，搜索maven关键字，选择安装红框对应的Maven插件。

Maven环境配置

点击Window -> Preferences

以下图所示，配置settings.xml文件的位置

建立Maven工程

File -> New -> Maven Project -> Next，在接下来的窗口中会看到一大堆的项目模板，选择合适的模板。

接下来设置项目的参数，以下：

groupId是项目组织惟一的标识符，实际对应JAVA的包的结构，是main目录里java的目录结构。

artifactId就是项目的惟一的标识符，实际对应项目的名称，就是项目根目录的名称。

点击Finish，Eclipse会建立一个Maven工程。

使用Maven进行构建

Eclipse中构建方式

在Elipse项目上右击 -> Run As 就能看到不少Maven操做。这些操做和maven命令是等效的。例如Maven clean，等同于mvn clean命令。

你也能够点击Maven build，输入组合命令，并保存下来。以下图：

Maven命令构建方式

固然，你也能够直接使用maven命令进行构建。

进入工程所在目录，输入maven命令就能够了。

以下图

使用指导

如何添加外部依赖jar包

在Maven工程中添加依赖jar包，很简单，只要在POM文件中引入对应的<dependency>标签便可。

参考下例：

<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">

<groupId>com.zp.maven</groupId>

<artifactId>MavenDemo</artifactId>

<version>0.0.1-SNAPSHOT</version>

<name>MavenDemo</name>

<url>http://maven.apache.org</url>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<junit.version>3.8.1</junit.version>

</properties>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>${junit.version}</version>

</dependency>

<scope>compile</scope>

</dependency>

</dependencies>

</project>

<dependency>标签最经常使用的四个属性标签：

groupId：项目组织惟一的标识符，实际对应JAVA的包的结构。

artifactId：项目惟一的标识符，实际对应项目的名称，就是项目根目录的名称。

version：jar包的版本号。能够直接填版本数字，也能够在properties标签中设置属性值。

scope：jar包的做用范围。能够填写compile、runtime、test、system和provided。用来在编译、测试等场景下选择对应的classpath。

如何寻找jar包

能够在http://mvnrepository.com/站点搜寻你想要的jar包版本

例如，想要使用log4j，能够找到须要的版本号，而后拷贝对应的maven标签信息，将其添加到pom .xml文件中。

如何使用Maven插件(Plugin)

要添加Maven插件，能够在pom.xml文件中添加<plugin>标签。

<build>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-compiler-plugin</artifactId>

</configuration>

</plugin>

</plugins>

</build>

<configuration>标签用来配置插件的一些使用参数。

如何一次编译多个工程

在Maven中，容许一个Maven Project中有多个Maven Module

1.建立maven父工程步骤：new-->other-->选择maven project-->next-->勾选create a simple project-->next-->填写Group Id、Artifact Id、Version --> packaging选择pom-->finish。

2.建立maven子工程步骤：选中刚才建立的父工程右键-->new-->other-->选择maven module-->next-->勾选create a simple project-->填写module name（其实就是artifact id）-->next-->GAV继承父工程-->packaging选择你须要的-->finish。

3.完成，刷新父工程；若有多个子工程，继续按照第二步骤建立。

这时打开XXX中的pom.xml能够看到其中有如下标签

</modules>

选择编译XXX时，会依次对它的全部Module执行相同操做。

经常使用Maven插件

maven-antrun-plugin

http://maven.apache.org/plugins/maven-antrun-plugin/

maven-antrun-plugin能让用户在Maven项目中运行Ant任务。用户能够直接在该插件的配置以Ant的方式编写Target，而后交给该插件的run目标去执行。在一些由Ant往Maven迁移的项目中，该插件尤为有用。此外当你发现须要编写一些自定义程度很高的任务，同时又觉得Maven不够灵活时，也能够以Ant的方式实现之。maven-antrun-plugin的run目标一般与生命周期绑定运行。

maven-archetype-plugin

http://maven.apache.org/archetype/maven-archetype-plugin/

Archtype指项目的骨架，Maven初学者最开始执行的Maven命令可能就是mvn archetype:generate，这实际上就是让maven-archetype-plugin生成一个很简单的项目骨架，帮助开发者快速上手。可能也有人看到一些文档写了mvn archetype:create，但实际上create目标已经被弃用了，取而代之的是generate目标，该目标使用交互式的方式提示用户输入必要的信息以建立项目，体验更好。 maven-archetype-plugin还有一些其余目标帮助用户本身定义项目原型，例如你由一个产品须要交付给不少客户进行二次开发，你就能够为他们提供一个Archtype，帮助他们快速上手。

maven-assembly-plugin

http://maven.apache.org/plugins/maven-assembly-plugin/

maven-assembly-plugin的用途是制做项目分发包，该分发包可能包含了项目的可执行文件、源代码、readme、平台脚本等等。 maven-assembly-plugin支持各类主流的格式如zip、tar.gz、jar和war等，具体打包哪些文件是高度可控的，例如用户能够按文件级别的粒度、文件集级别的粒度、模块级别的粒度、以及依赖级别的粒度控制打包，此外，包含和排除配置也是支持的。maven-assembly- plugin要求用户使用一个名为assembly.xml的元数据文件来表述打包，它的single目标能够直接在命令行调用，也能够被绑定至生命周期。

maven-dependency-plugin

http://maven.apache.org/plugins/maven-dependency-plugin/

maven-dependency-plugin最大的用途是帮助分析项目依赖，dependency:list可以列出项目最终解析到的依赖列表，dependency:tree能进一步的描绘项目依赖树，dependency:analyze能够告诉你项目依赖潜在的问题，若是你有直接使用到的却未声明的依赖，该目标就会发出警告。maven-dependency-plugin还有不少目标帮助你操做依赖文件，例如dependency:copy-dependencies能将项目依赖从本地Maven仓库复制到某个特定的文件夹下面。

maven-enforcer-plugin

http://maven.apache.org/plugins/maven-enforcer-plugin/

在一个稍大一点的组织或团队中，你没法保证全部成员都熟悉Maven，那他们作一些比较愚蠢的事情就会变得很正常，例如给项目引入了外部的 SNAPSHOT依赖而致使构建不稳定，使用了一个与你们不一致的Maven版本而常常抱怨构建出现诡异问题。maven-enforcer- plugin可以帮助你避免之类问题，它容许你建立一系列规则强制你们遵照，包括设定Java版本、设定Maven版本、禁止某些依赖、禁止 SNAPSHOT依赖。只要在一个父POM配置规则，而后让你们继承，当规则遭到破坏的时候，Maven就会报错。除了标准的规则以外，你还能够扩展该插件，编写本身的规则。maven-enforcer-plugin的enforce目标负责检查规则，它默认绑定到生命周期的validate阶段。

maven-help-plugin

http://maven.apache.org/plugins/maven-help-plugin/

maven-help-plugin是一个小巧的辅助工具，最简单的help:system能够打印全部可用的环境变量和Java系统属性。help:effective-pom和help:effective-settings最为有用，它们分别打印项目的有效POM和有效settings，有效POM是指合并了全部父POM（包括Super POM）后的XML，当你不肯定POM的某些信息从何而来时，就能够查看有效POM。有效settings同理，特别是当你发现本身配置的 settings.xml没有生效时，就能够用help:effective-settings来验证。此外，maven-help-plugin的describe目标能够帮助你描述任何一个Maven插件的信息，还有all-profiles目标和active-profiles目标帮助查看项目的Profile。

maven-release-plugin

http://maven.apache.org/plugins/maven-release-plugin/

maven-release-plugin的用途是帮助自动化项目版本发布，它依赖于POM中的SCM信息。release:prepare用来准备版本发布，具体的工做包括检查是否有未提交代码、检查是否有SNAPSHOT依赖、升级项目的SNAPSHOT版本至RELEASE版本、为项目打标签等等。release:perform则是签出标签中的RELEASE源码，构建并发布。版本发布是很是琐碎的工做，它涉及了各类检查，并且因为该工做仅仅是偶尔须要，所以手动操做很容易遗漏一些细节，maven-release-plugin让该工做变得很是快速简便，不易出错。maven-release-plugin的各类目标一般直接在命令行调用，由于版本发布显然不是平常构建生命周期的一部分。

maven-resources-plugin

http://maven.apache.org/plugins/maven-resources-plugin/

为了使项目结构更为清晰，Maven区别对待Java代码文件和资源文件，maven-compiler-plugin用来编译Java代码，maven-resources-plugin则用来处理资源文件。默认的主资源文件目录是src/main/resources，不少用户会须要添加额外的资源文件目录，这个时候就能够经过配置maven-resources-plugin来实现。此外，资源文件过滤也是Maven的一大特性，你能够在资源文件中使用${propertyName}形式的Maven属性，而后配置maven-resources-plugin开启对资源文件的过滤，以后就能够针对不一样环境经过命令行或者Profile传入属性的值，以实现更为灵活的构建。

maven-surefire-plugin

http://maven.apache.org/plugins/maven-surefire-plugin/

多是因为历史的缘由，Maven 2/3中用于执行测试的插件不是maven-test-plugin，而是maven-surefire-plugin。其实大部分时间内，只要你的测试类遵循通用的命令约定（以Test结尾、以TestCase结尾、或者以Test开头），就几乎不用知晓该插件的存在。然而在当你想要跳过测试、排除某些测试类、或者使用一些TestNG特性的时候，了解maven-surefire-plugin的一些配置选项就颇有用了。例如 mvn test -Dtest=FooTest 这样一条命令的效果是仅运行FooTest测试类，这是经过控制maven-surefire-plugin的test参数实现的。

build-helper-maven-plugin

http://mojo.codehaus.org/build-helper-maven-plugin/

Maven默认只容许指定一个主Java代码目录和一个测试Java代码目录，虽然这实际上是个应当尽可能遵照的约定，但偶尔你仍是会但愿可以指定多个源码目录（例如为了应对遗留项目），build-helper-maven-plugin的add-source目标就是服务于这个目的，一般它被绑定到默认生命周期的generate-sources阶段以添加额外的源码目录。须要强调的是，这种作法仍是不推荐的，由于它破坏了 Maven的约定，并且可能会遇到其余严格遵照约定的插件工具没法正确识别额外的源码目录。

build-helper-maven-plugin的另外一个很是有用的目标是attach-artifact，使用该目标你能够以classifier的形式选取部分项目文件生成附属构件，并同时install到本地仓库，也能够deploy到远程仓库。

exec-maven-plugin

http://mojo.codehaus.org/exec-maven-plugin/

exec-maven-plugin很好理解，顾名思义，它能让你运行任何本地的系统程序，在某些特定状况下，运行一个Maven外部的程序可能就是最简单的问题解决方案，这就是exec:exec的用途，固然，该插件还容许你配置相关的程序运行参数。除了exec目标以外，exec-maven-plugin还提供了一个java目标，该目标要求你提供一个mainClass参数，而后它可以利用当前项目的依赖做为classpath，在同一个JVM中运行该mainClass。有时候，为了简单的演示一个命令行Java程序，你能够在POM中配置好exec-maven-plugin的相关运行参数，而后直接在命令运行mvn exec:java 以查看运行效果。

jetty-maven-plugin

http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin

在进行Web开发的时候，打开浏览器对应用进行手动的测试几乎是没法避免的，这种测试方法一般就是将项目打包成war文件，而后部署到Web容器中，再启动容器进行验证，这显然十分耗时。为了帮助开发者节省时间，jetty-maven-plugin应运而生，它彻底兼容 Maven项目的目录结构，可以周期性地检查源文件，一旦发现变动后自动更新到内置的Jetty Web容器中。作一些基本配置后（例如Web应用的contextPath和自动扫描变动的时间间隔），你只要执行 mvn jetty:run ，而后在IDE中修改代码，代码经IDE自动编译后产生变动，再由jetty-maven-plugin侦测到后更新至Jetty容器，这时你就能够直接测试Web页面了。须要注意的是，jetty-maven-plugin并非宿主于Apache或Codehaus的官方插件，所以使用的时候须要额外的配置settings.xml的pluginGroups元素，将org.mortbay.jetty这个pluginGroup加入。

versions-maven-plugin

http://mojo.codehaus.org/versions-maven-plugin/

不少Maven用户遇到过这样一个问题，当项目包含大量模块的时候，为他们集体更新版本就变成一件烦人的事情，到底有没有自动化工具能帮助完成这件事情呢？（固然你可使用sed之类的文本操做工具，不过不在本文讨论范围）答案是确定的，versions-maven- plugin提供了不少目标帮助你管理Maven项目的各类版本信息。例如最经常使用的，命令 mvn versions:set -DnewVersion=1.1-SNAPSHOT 就能帮助你把全部模块的版本更新到1.1-SNAPSHOT。该插件还提供了其余一些颇有用的目标，display-dependency- updates能告诉你项目依赖有哪些可用的更新；相似的display-plugin-updates能告诉你可用的插件更新；而后use- latest-versions能自动帮你将全部依赖升级到最新版本。最后，若是你对所作的更改满意，则可使用 mvn versions:commit 提交，不满意的话也可使用 mvn versions:revert 进行撤销。

更多详情请参考https://maven.apache.org/plugins/

经常使用Maven命令

生命周期	阶段描述
mvn validate	验证项目是否正确，以及全部为了完整构建必要的信息是否可用
mvn generate-sources	生成全部须要包含在编译过程当中的源代码
mvn process-sources	处理源代码，好比过滤一些值
mvn generate-resources	生成全部须要包含在打包过程当中的资源文件
mvn process-resources	复制并处理资源文件至目标目录，准备打包
mvn compile	编译项目的源代码
mvn process-classes	后处理编译生成的文件，例如对Java类进行字节码加强（bytecode enhancement）
mvn generate-test-sources	生成全部包含在测试编译过程当中的测试源码
mvn process-test-sources	处理测试源码，好比过滤一些值
mvn generate-test-resources	生成测试须要的资源文件
mvn process-test-resources	复制并处理测试资源文件至测试目标目录
mvn test-compile	编译测试源码至测试目标目录
mvn test	使用合适的单元测试框架运行测试。这些测试应该不须要代码被打包或发布
mvn prepare-package	在真正的打包以前，执行一些准备打包必要的操做。这一般会产生一个包的展开的处理过的版本（将会在Maven 2.1+中实现）
mvn package	将编译好的代码打包成可分发的格式，如JAR，WAR，或者EAR
mvn pre-integration-test	执行一些在集成测试运行以前须要的动做。如创建集成测试须要的环境
mvn integration-test	若是有必要的话，处理包并发布至集成测试能够运行的环境
mvn post-integration-test	执行一些在集成测试运行以后须要的动做。如清理集成测试环境。
mvn verify	执行全部检查，验证包是有效的，符合质量规范
mvn install	安装包至本地仓库，以备本地的其它项目做为依赖使用
mvn deploy	复制最终的包至远程仓库，共享给其它开发人员和项目（一般和一次正式的发布相关）

使用参数

-Dmaven.test.skip=true: 跳过单元测试(eg: mcn clean package -Dmaven.test.skip=true)

常见问题

dependencies和dependencyManagement，plugins和

pluginManagement

有什么区别？

dependencyManagement是表示依赖jar包的声明，即你在项目中的dependencyManagement下声明了依赖，maven不会加载该依赖，dependencyManagement声明能够被继承。

dependencyManagement的一个使用案例是当有父子项目的时候，父项目中能够利用dependencyManagement声明子项目中须要用到的依赖jar包，以后，当某个或者某几个子项目须要加载该插件的时候，就能够在子项目中dependencies节点只配置 groupId 和 artifactId就能够完成插件的引用。

dependencyManagement主要是为了统一管理插件，确保全部子项目使用的插件版本保持一致，相似的仍是plugins和pluginManagement。

参考资料

https://maven.apache.org/index.html ——官方文档地址

http://www.oschina.net/question/158170_29368

http://www.cnblogs.com/crazy-fox/archive/2012/02/09/2343722.html