Maven"妹问"不是"妈问"

pache Maven 入门篇 ( 上 ) | Oracle 中国

Apache Maven 入门篇 ( 下 ) | Oracle 中国

 

写这个 maven 的入门篇是因为之前在一个开发者会的动手实验中发现挺多人对于 maven 不是那么了解，所以就有了这个想法。

这个入门篇分上下两篇。本文着重动手，用 maven 来构建运行 hellow world 程序，体会一下不用任何 IDE ，只用 maven 是咋回事。然后下篇就讲解一下 maven 的核心概念。写这两篇文章特意回避了复杂的示例，也不使用 IDE ，目的是排除干扰，着重于 maven 本身。

本文的源代码可从这里 下载。

Apache Maven 是做什么用的？

Maven 是一个项目管理和构建自动化工具。但是对于我们程序员来说，我们最关心的是它的项目构建功能。所以这里我们介绍的就是怎样 用 maven 来满足我们项目的日常需要。 Maven 使用惯例优于配置的原则 。它要求在没有定制之前，所有的项目都有如下的结构：

目录 目的
${basedir} 存放 pom.xml和所有的子目录
${basedir}/src/main/java 项目的 java源代码
${basedir}/src/main/resources 项目的资源，比如说 property文件
${basedir}/src/test/java 项目的测试类，比如说 JUnit代码
${basedir}/src/test/resources 测试使用的资源

一个 maven 项目在默认情况下会产生 JAR 文件，另外 ，编译后 的 classes 会放在 ${basedir}/target/classes 下面， JAR 文件会放在 ${basedir}/target 下面。这时有人会说了 ， Ant 就没有那么多要求 ，它允许你可以自由的定义项目的结构。在这里不想引起口水战哈， 我个人觉得 maven 的这些默认定义很方便使用。 好了 ，接下来我们来安装 maven 。

Maven 的安装

在安装 maven 前，先保证你安装了 JDK 。 JDK 6 可以从 Oracle 技术网上下载： http://www.oracle.com/technetwork/cn/java/javase/downloads/index.html。 Maven 官网的下载链接是 : http://maven.apache.org/download.html 。该页的最后给出了安装指南。

安装完成后，在命令行运行下面的命令：

$ mvn -v
Apache Maven 3.0.3 (r1075438; 2011-03-01 01:31:09+0800)
Maven home: /home/limin/bin/maven3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: /home/limin/bin/jdk1.6.0_24/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.35-28-generic-pae", arch: "i386", family: "unix"

如果你看到类似上面的输出的话，就说明安装成功了。

接下来我们用 maven 来建立最著名的“Hello World!”程序 :)

注意：如果你是第一次运行 maven，你需要 Internet 连接，因为 maven 需要从网上下载需要的插件。

我们要做的第一步是建立一个 maven 项目。在 maven 中，我们是执行 maven 目标 (goal) 来做事情的。

maven 目标和 ant 的 target 差不多。在命令行中执行下面的命令来建立我们的 hello world 项目

mvn archetype:generate -DgroupId=com.mycompany.helloworld -DartifactId=helloworld -Dpackage=com.mycompany.helloworld -Dversion=1.0-SNAPSHOT

 

 

 

archetype:generate 目标会列出一系列的 archetype 让你选择。 Archetype 可以理解成项目的模型。Maven 为我们提供了很多种的项目模型，包括从简单的 Swing 到复杂的 Web 应用。我们选择默认的 maven-archetype-quickstart ，是编号 #106 ，如下图所示：

连打两个回车，这时候让你确定项目属性的配置，

这些属性是我们在命令行中用 -D 选项指定的。该选项使用 -Dname=value 的格式。回车确认，就完成了项目的建立，如下图所示：

这时候我们看一下 maven 给我们建立的文件目录结构：

maven 的 archetype 插件建立了一个 helloworld 目录，这个名字来自 artifactId 。在这个目录下面，有一个 Project Object Model(POM) 文件 pom.xml 。这个文件用于描述项目，配置插件和管理依赖关系。源代码和资源文件放在 src/main 下面，而测试代码和资源放在 src/test 下面。

Maven 已经为我们建立了一个 App.java 文件：

Java代码

package com.mycompany.helloworld;   
      
    /**  
     * Hello world!  
     *  
     */   
    public class App {   

      
        public static void main( String[] args ) {   
            System.out.println( "Hello World!" );   
        }   
    }

正是我们需要的 Hello World 代码。所以我们可以构建和运行这个程序了。用下面简单的命令构建：

~$cd helloworld

~$mvn package

当你第一次运行 maven 的时候，它会从网上的 maven 库 (repository) 下载需要的程序，存放在你电脑的本地库 (local repository) 中，所以这个时候你需要有 Internet 连接。Maven 默认的本地库是 ~/.m2/repository/，在 Windows 下是 %USER_HOME%\.m2\repository\ 。

如果构建没有错误的话，就会得到类似下面的结果：

这个时候， maven 在 helloworld 下面建立了一个新的目录 target/ ，构建打包后的 jar 文件 helloworld-1.0-SNAPSHOT.jar 就存放在这个目录下。编译后的 class 文件放在 target/classes/ 目录下面，测试 class 文件放在 target/test-classes/ 目录下面。

为了验证我们的程序能运行，执行下面的命令：

~$java -cp target/helloworld-1.0-SNAPSHOT.jar com.mycompany.helloworld.App

运行成功！！

现在你可能会有不少的问题。所以下一篇文章会解释 maven 的核心概念，希望能回答你可能会有的一些疑问。

 

第一篇文章大概的介绍了一下Apache Maven以及它的下载和安装，并且运行了一个简单的示例。那么在对maven有了一点接触后，接下去的一步是要了解maven的核心概念，这样才能在使用maven的时候游刃有余。

接下来我们介绍下面这几个核心概念：

POM (Project Object Model)Maven 插件Maven 生命周期Maven 依赖管理Maven 库

POM (Project Object Model)一个项目所有的配置都放置在 POM 文件中：定义项目的类型、名字，管理依赖关系，定制插件的行为等等。比如说，你可以配置 compiler 插件让它使用 java 1.5 来编译。 现在看一下第一篇文章中示例的 POM

Xml 代码

<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.mycompany.helloworld</groupId>
  <artifactId>helloworld</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>helloworld</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>

在 POM 中，groupId, artifactId, packaging, version 叫作 maven 坐标，它能唯一的确定一个项目。有了 maven 坐标，我们就可以用它来指定我们的项目所依赖的其他项目，插件，或者父项目。一般 maven 坐标写成如下的格式：

groupId:artifactId:packaging:version

像我们的例子就会写成：

com.mycompany.helloworld: helloworld: jar: 1.0-SNAPSHOT

我们的 helloworld 示例很简单，但是大项目一般会分成几个子项目。在这种情况下，每个子项目就会有自己的 POM 文件，然后它们会有一个共同的父项目。这样只要构建父项目就能够构建所有的子项目了。子项目的 POM 会继承父项目的 POM。另外，所有的 POM都继承了一个 Super-POM。Super-POM 设置了一些默认值，比如在第一篇文章中提到的默认的目录结构，默认的插件等等，它遵循了惯例优于配置的原则。所以尽管我们的这个 POM 很简单，但是这只是你看得见的一部分。运行时候的 POM 要复杂的多。 如果你想看到运行时候的 POM 的全部内容的话，可以运行下面的命令：

$mvn help:effective-pom

Maven 插件

在第一篇文章中，我们用了 mvn archetype:generate 命令来生成一个项目。那么这里的 archetype:generate 是什么意思呢？archetype 是一个插件的名字，generate是目标(goal)的名字。这个命令的意思是告诉 maven 执行 archetype 插件的 generate 目标。插件目标通常会写成 pluginId:goalId

一个目标是一个工作单元，而插件则是一个或者多个目标的集合。比如说Jar插件，Compiler插件，Surefire插件等。从看名字就能知道，Jar 插件包含建立Jar文件的目标， Compiler 插件包含编译源代码和单元测试代码的目标。Surefire 插件的话，则是运行单元测试

看到这里，估计你能明白了，mvn 本身不会做太多的事情，它不知道怎么样编译或者怎么样打包。它把构建的任务交给插件去做。插件定义了常用的构建逻辑，能够被重复利用。这样做的好处是，一旦插件有了更新，那么所有的 maven 用户都能得到更新。

Maven 生命周期

在第一篇文章中，我们用的第二个命令是：mvn package。这里的 package 是一个maven的生命周期阶段 (lifecycle phase )。生命周期指项目的构建过程，它包含了一系列的有序的阶段 (phase)，而一个阶段就是构建过程中的一个步骤。

那么生命周期阶段和上面说的插件目标之间是什么关系呢？插件目标可以绑定到生命周期阶段上。一个生命周期阶段可以绑定多个插件目标。当 maven 在构建过程中逐步的通过每个阶段时，会执行该阶段所有的插件目标。

maven 能支持不同的生命周期，但是最常用的是默认的Maven生命周期 (default Maven lifecycle )。如果你没有对它进行任何的插件配置或者定制的话，那么上面的命令 mvn package 会依次执行默认生命周期中直到包括 package 阶段前的所有阶段的插件目标：

process-resources 阶段：resources:resources

compile 阶段：compiler:compile

process-classes 阶段：(默认无目标)

process-test-resources 阶段：resources:testResources

test-compile 阶段：compiler:testCompile

test 阶段：surefire:test

prepare-package 阶段：(默认无目标)

package 阶段：jar:jar

Maven 依赖管理

之前我们说过，maven 坐标能够确定一个项目。换句话说，我们可以用它来解决依赖关系。在 POM 中，依赖关系是在 dependencies 部分中定义的。在上面的 POM 例子中，我们用 dependencies 定义了对于 junit 的依赖：

Xml 代码

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

那这个例子很简单，但是实际开发中我们会有复杂得多的依赖关系，因为被依赖的 jar 文件会有自己的依赖关系。那么我们是不是需要把那些间接依赖的 jar 文件也都定义在POM中呢？答案是不需要，因为 maven 提供了传递依赖的特性。

所谓传递依赖是指 maven 会检查被依赖的 jar 文件，把它的依赖关系纳入最终解决的依赖关系链中。针对上面的 junit 依赖关系，如果你看一下 maven 的本地库（我们马上会解释 maven 库）~/.m2/repository/junit/junit/3.8.1/ ，

你会发现 maven 不但下载了 junit-3.8.1.jar，还下载了它的 POM 文件。这样 maven 就能检查 junit的依赖关系，把它所需要的依赖也包括进来。

在 POM 的 dependencies 部分中，scope 决定了依赖关系的适用范围。我们的例子中 junit 的 scope 是 test，那么它只会在执行 compiler:testCompile and surefire:test目标的时候才会被加到 classpath 中，在执行 compiler:compile 目标时是拿不到 junit 的。

我们还可以指定 scope 为 provided，意思是 JDK 或者容器会提供所需的jar文件。比如说在做web应用开发的时候，我们在编译的时候需要 servlet API jar 文件，但是在打包的时候不需要把这个 jar 文件打在 WAR 中，因为servlet容器或者应用服务器会提供的。

scope 的默认值是 compile，即任何时候都会被包含在 classpath 中，在打包的时候也会被包括进去。

 

Maven 库

当第一次运行 maven 命令的时候，你需要 Internet 连接，因为它要从网上下载一些文件。那么它从哪里下载呢？它是从 maven 默认的远程库(http://repo1.maven.org/maven2) 下载的。这个远程库有 maven 的核心插件和可供下载的 jar 文件。

但是不是所有的 jar 文件都是可以从默认的远程库下载的，比如说我们自己开发的项目。这个时候，有两个选择：要么在公司内部设置定制库，要么手动下载和安装所需的jar文件到本地库。

本地库是指 maven 下载了插件或者 jar 文件后存放在本地机器上的拷贝。在 Linux 上，它的位置在 ~/.m2/repository，在 Windows XP 上，在 C:\Documents and Settings\username\.m2\repository ，在 Windows 7 上，在 C:\Users\username\.m2\repository。当 maven 查找需要的 jar 文件时，它会先在本地库中寻找，只有在找不到的情况下，才会去远程库中找。

运行下面的命令能把我们的 helloworld 项目安装到本地库：

$mvn install

一旦一个项目被安装到了本地库后，你别的项目就可以通过 maven 坐标和这个项目建立依赖关系。比如如果我现在有一个新项目需要用到 helloworld，那么在运行了上面的 mvn install 命令后，我就可以如下所示来建立依赖关系：

Xml 代码

<dependency>
      <groupid>com.mycompany.helloworld</groupid>
      <artifactid>helloworld</artifactid>
      <version>1.0-SNAPSHOT</version>
    </dependency>

好了，maven 的核心概念就简单的介绍到这里。至于在 Eclipse 中如何使用 maven，这个网上很多了，google 一下就行。

 dependencyManagement使用简介_徐小冠-CSDN博客_dependencymanagement

5）Maven 的 conf 目录下包含了一个非常重要的文件 settings.xml，一般情况下，我倾向于将该文件复制到 ~/.m2/ 目录下——建议你也这么做。

打开该文件，在 <mirrors></mirrors> 节点下添加阿里云的镜像地址（参照下面的代码）。为什么要这么做呢？因为 Maven 默认的仓库在不翻强的情况下很难访问到。

<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>

这里需要注意的是，<mirrorOf> 的值有下面四种方式：

  • <mirrorOf>*<mirrorOf>：匹配所有远程仓库，也就是说任何对于中央仓库的请求都会转至该镜像。
  • <mirrorOf>external:*<mirrorOf>：匹配所有不在本机上的远程仓库。
  • <mirrorOf>repo1,repo2<mirrorOf>：匹配仓库 repo1 和 repo2，使用逗号分隔多个远程仓库。
  • <mirrorOf>*,!repo<mirrorOf>：匹配所有远程仓库，repo 除外，使用感叹号将仓库从匹配中排除。

Maven入门，读这篇文章就够了 - 沉默王二博客

  • 设置Maven全局变量：在.bash_prodile或者.zshrc中添加对应的内容
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_76.jdk/Contents/Home/         
export M2_HOME=/Users/zhangguanghui/Public/apache-maven-3.3.9 
export M2=$M2_HOME/bin:$PATH export MAVEN_OPTS="-Xms256m -Xmx512m"

JAVA_HOME是电脑中的Java路径，M2_HOME是Maven的解压路径，MAVEN_OPTS是maven的jvm配置。这个地方根据自己的位置而定，这个是MAC的安装配置。

 

我们都知道Maven本质上是一个插件框架，它的核心并不执行任何具体的构建任务，所有这些任务都交给插件来完成，例如编译源代码是由maven- compiler-plugin完成的。进一步说，每个任务对应了一个插件目标（goal），每个插件会有一个或者多个目标，例如maven- compiler-plugin的compile目标用来编译位于src/main/java/目录下的主源码，testCompile目标用来编译位于src/test/java/目录下的测试源码。

 

用户可以通过两种方式调用Maven插件目标。第一种方式是将插件目标与生命周期阶段（lifecycle phase）绑定，这样用户在命令行只是输入生命周期阶段而已，例如Maven默认将maven-compiler-plugin的compile目标与 compile生命周期阶段绑定，因此命令mvn compile实际上是先定位到compile这一生命周期阶段，然后再根据绑定关系调用maven-compiler-plugin的compile目标。第二种方式是直接在命令行指定要执行的插件目标，例如mvn archetype:generate 就表示调用maven-archetype-plugin的generate目标，这种带冒号的调用方式与生命周期无关。

 

认识上述Maven插件的基本概念能帮助你理解Maven的工作机制，不过要想更高效率地使用Maven，了解一些常用的插件还是很有必要的，这可 以帮助你避免一不小心重新发明轮子。多年来Maven社区积累了大量的经验，并随之形成了一个成熟的插件生态圈。Maven官方有两个插件列表，第一个列 表的GroupId为org.apache.maven.plugins，这里的插件最为成熟，具体地址为：http://maven.apache.org/plugins/index.html。第二个列表的GroupId为org.codehaus.mojo，这里的插件没有那么核心，但也有不少十分有用，其地址为：http://mojo.codehaus.org/plugins.html。

 

接下来笔者根据自己的经验介绍一些最常用的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 进行撤销。

 

# 小结

 

本文介绍了一些最常用的Maven插件，这里指的“常用”是指经常需要进行配置的插件，事实上我们用Maven的时候很多其它插件也是必须的，例如 默认的编译插件maven-compiler-plugin和默认的打包插件maven-jar-plugin，但因为很少需要对它们进行配置，因此不在 本文讨论范围。了解常用的Maven插件能帮助你事倍功半地完成项目构建任务，反之你就可能会因为经常遇到一些难以解决的问题而感到沮丧。本文介绍的插件 基本能覆盖大部分Maven用户的日常使用需要，如果你真有非常特殊的需求，自行编写一个Maven插件也不是难事，更何况还有这么多开放源代码的插件供 你参考。

 

本文的这个插件列表并不是一个完整列表，读者有兴趣的话也可以去仔细浏览一下Apache和Codehaus Mojo的Maven插件列表，以的到一个更为全面的认识。最后，在线的Maven仓库搜索引擎如http://search.maven.org/也能帮助你快速找到自己感兴趣的Maven插件。

Maven高效实践_一品江南-CSDN博客

 

说明

  1. 一直在用 Mindjet MindManager 做思维导图。以前在用思维导图写读书笔记时，总是想要事无巨细地写清楚每个知识点，现在想来是事倍功半。思维导图应该是一个帮助我们梳理知识点、理清思路的工具，而不是一个像字典式的工具。
  2. 最近在学 Spring，结合 Maven 感觉到了一点：约定优于配置。为了获得代码的简洁，用户是需要付出一定代价的——遵循约定。Spring 的 DI，完全依赖注解，使得代码大大简化，但是我们也必须遵守规则。
  3. 如果没有约定，那么每个人对每个项目都有额外的学习成本。如果仅仅是因为喜好，就不要打破约定。个性往往意味着牺牲通用性，意味着增加无谓的复杂度。

目录

目录
目录

简介

简介
简介

使用入门

使用入门
使用入门

坐标和依赖

坐标和依赖
坐标和依赖

仓库

仓库
仓库

生命周期和插件

生命周期和插件
生命周期和插件

聚合与继承

聚合与继承
聚合与继承

4. Maven之setting.xml配置文件详解

 

settings.xml是maven的全局配置文件。而pom.xml文件是所在项目的局部配置。

 

4.1 setting.xml文件位置

 

settings.xml文件一般存在于两个位置：

 

  • 全局配置: ${M2_HOME}/conf/settings.xml

  • 用户配置: user.home/.m2/settings.xml

 

前者叫做全局配置，对操作系统的所有使用者生效；后者为用户配置，只对当前操作系统的使用者生效。

 

4.2 配置文件优先级

 

局部配置优先于全局配置。

 

配置优先级从高到低：pom.xml> user settings > global settings

 

如果这些文件同时存在，在应用配置时，会合并它们的内容，如果有重复的配置，优先级高的配置会覆盖优先级低的。如果全局配置和用户配置都存在，它们的内容将被合并，并且用户范围的settings.xml会覆盖全局的settings.xml。

 

4.3 配置文件注意事项

 

  • note1: Maven安装后，用户目录下不会自动生成settings.xml，只有全局配置文件。如果需要创建用户范围的settings.xml，可以将安装路径下的settings复制到目录${user.home}/.m2/。Maven默认的settings.xml是一个包含了注释和例子的模板，可以快速的修改它来达到你的要求。

  • note2: 全局配置一旦更改，所有的用户都会受到影响，而且如果maven进行升级，所有的配置都会被清除，所以要提前复制和备份${M2_HOME}/conf/settings.xml文件，一般情况下不推荐配置全局的settings.xml。

[maven][spring boot] mvn -f 指定 pom 文件_mvn 指定 pom-CSDN 博客

前言

  • spring boot 2.0 + mvn 3.5 项目
  • 测试环境中运行 spring boot 时，需要指定属性文件为：application-test
  • 使用 方式时，指定属性文件未起效
  • 经过尝试，pom 文件中包含 spring-boot-devtools，导致 spring.config.name 参数失效所致。
  • 为此添加 pom-test.xml 用于测试环境。

MAVEN 指定 pom 文件

mvn -f pom-test.xml spring-boot:run -Dspring.config.name=application-test
posted @ 2022-03-03 10:43  CharyGao  阅读(43)  评论(0)  编辑  收藏  举报