前言：目前所有的項目都在使用maven，可是一直沒有時間去整理學習，這兩天正好有時間，好好的整理一下。

一、爲什麼使用Maven這樣的構建工具【why】

① 一個項目就是一個工程

如果項目非常龐大，就不適合使用package來劃分模塊，最好是每一個模塊對應一個工程，利於分工協作。藉助於maven就可以將一個項目拆分成多個工程

② 項目中使用jar包，需要“複製”、“粘貼”項目的lib中

同樣的jar包重複的出現在不同的項目工程中，你需要做不停的複製粘貼的重複工作。藉助於maven，可以將jar包保存在“倉庫”中，不管在哪個項目只要使用引用即可就行。

③ jar包需要的時候每次都要自己準備好或到官網下載

藉助於maven我們可以使用統一的規範方式下載jar包，規範

④ jar包版本不一致的風險

不同的項目在使用jar包的時候，有可能會導致各個項目的jar包版本不一致，導致未執行錯誤。藉助於maven，所有的jar包都放在“倉庫”中，所有的項目都使用倉庫的一份jar包。

⑤ 一個jar包依賴其他的jar包需要自己手動的加入到項目中

FileUpload組件->IO組件，commons-fileupload-1.3.jar依賴於commons-io-2.0.1.jar

極大的浪費了我們導入包的時間成本，也極大的增加了學習成本。藉助於maven，它會自動的將依賴的jar包導入進來。

二、maven是什麼【what】

① maven是一款服務於java平臺的自動化構建工具

make->Ant->Maven->Gradle

名字叫法：我們可以叫妹文也可以叫麥文，但是沒有叫媽文的。

② 構建

構建定義：把動態的Web工程經過編譯得到的編譯結果部署到服務器上的整個過程。

編譯：java源文件[.java]->編譯->Classz字節碼文件[.class]

部署：最終在sevlet容器中部署的不是動態web工程，而是編譯後的文件

③ 構建的各個環節

清理clean：將以前編譯得到的舊文件class字節碼文件刪除
編譯compile：將java源程序編譯成class字節碼文件
測試test：自動測試，自動調用junit程序
報告report：測試程序執行的結果
打包package：動態Web工程打War包，java工程打jar包
安裝install：Maven特定的概念-----將打包得到的文件複製到“倉庫”中的指定位置
部署deploy：將動態Web工程生成的war包複製到Servlet容器下，使其可以運行

三、安裝maven

① 當前系統是否配置JAVA_HOME的環境變量

② 下載maven，解壓maven放在一個非中文無空格的路徑下

③ 配置maven的相關環境變量

在環境變量增加M2_HOME，路徑是maven解壓後的根目錄
在環境變量裏的path中增加maven/bin的目錄

④ 驗證：maven -v 查看maven版本

看到版本信息，恭喜你已經OK了。

四、第一個maven

① 創建約定的目錄結構（maven工程必須按照約定的目錄結構創建）

根目錄：工程名
|—src：源碼
|—|---main:存放主程序
|—|---|—java：java源碼文件
|—|---|—resource：存放框架的配置文件
|—|---test：存放測試程序
|—pop.xml：maven的核心配置文件

我們按照上面的文件夾目錄結構手動創建一下，不用任何IDE環境（手動的其實最有助於我們理解maven）

文件內容如下

在src/main/java/cn/andyoung/hellomaven/controller，內容如下

package cn.andyoung.hellomaven.controller;

public class Hello {
  public String sayHello(String name) {
    return "Hello " + name + "!";
  }
}

POM文件內容：

<?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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.7.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>cn.andyoung</groupId>
    <artifactId>hello-maven</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>hello-maven</name>
    <description>Demo project for Spring Boot</description>

    <properties>
        <java.version>1.8</java.version>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

</project>

② 常用maven命令

mvn clean：清理
mvn compile：編譯主程序
mvn test-compile：編譯測試程序
mvn test：執行測試
mvn package：打包

執行maven命令必須進入到pom.xml的目錄中進行執行

進入到項目的pom.xml目錄之後，就可以執行啦。

1、運行 mvn compile

OK，運行完畢，你在pom.xml配置的依賴的包已經導入到倉庫了，問題來了，倉庫默認的位置在哪？

倉庫的默認位置： c:\Usrs[登錄當前系統的用戶名].m2\repository

剛纔執行完compile之後，之前的文件夾發生了變化

2、運行mvn test-compile，target文件夾下面除了classes之外多了test-classes文件夾

3、運行mvn package，target文件夾下面又多了一個打好的jar包

4、運行mvn clean，發現整個target文件夾都沒了。又回到了編譯之前我們手動創建的文件夾

五、倉庫和座標

① pom.xml： Project Object Model 項目對象模型。它是maven的核心配置文件，所有的構建的配置都在這裏設置。

② 座標 使用下面的三個向量在倉庫中唯一的定位一個maven工程

       <dependency>
          	 <!-- 1、公司或者組織域名排序+項目名 -->
            <groupId>org.mybatis.generator</groupId>
             <!-- 2、模塊名 -->
            <artifactId>mybatis-generator-core</artifactId>
             <!-- 3、版本 -->
            <version>1.4.0</version>
        </dependency>

③ maven工程的座標與倉庫中路徑的關係：

maven座標和倉庫對應的映射關係：[groupId][artifactId][version][artifactId]-[version].jar

去本地倉庫看一下此目錄：org\springframework\spring-core\4.3.4.RELEASE\spring-core-4.3.4.RELEASE.jar

果然是完全對應的（默認倉庫地址上面說過了哦，不要說不知道在哪，沒事下面我們再說一下倉庫）

④ 倉庫

倉庫的分類：

1、本地倉庫： 當前電腦上的倉庫，路徑上已經說過了哦

2、遠程倉庫：

私服：搭建在局域網中，一般公司都會有私服，私服一般使用nexus來搭建。具體搭建過程可以查詢其他資料
中央倉庫：架設在Internet上，像剛纔的springframework就是在中央倉庫上

六、依賴

① maven解析依賴信息時會到本地倉庫中取查找被依賴的jar包

對於本地倉庫中沒有的會去中央倉庫去查找maven座標來獲取jar包，獲取到jar之後會下載到本地倉庫
對於中央倉庫也找不到依賴的jar包的時候，就會編譯失敗了

② 如果依賴的是自己或者團隊開發的maven工程，需要先使用install命令把被依賴的maven工程的jar包導入到本地倉庫中

舉例：現在我再創建第二個maven工程HelloFriend，其中用到了第一個Hello工程裏類的sayHello(String name)方法。我們在給HelloFriend項目使用 mvn compile命令進行編譯的時候，會提示缺少依賴Hello的jar包。怎麼辦呢？

到第一個maven工程中執行 mvn install後，你再去看一下本地倉庫，你會發現有了Hello項目的jar包。一旦本地倉庫有了依賴的maven工程的jar包後，你再到HelloFriend項目中使用 mvn compile命令的時候，可以成功編譯

③ 依賴範圍

scope就是依賴的範圍

1、compile， 默認值，適用於所有階段（開發、測試、部署、運行），本jar會一直存在所有階段。

2、provided， 只在開發、測試階段使用，目的是不讓Servlet容器和你本地倉庫的jar包衝突。如servlet.jar。

3、runtime， 只在運行時使用，如JDBC驅動，適用運行和測試階段。

4、test， 只在測試時使用，用於編譯和運行測試代碼。不會隨項目發佈。

5、system， 類似provided，需要顯式提供包含依賴的jar，Maven不會在Repository中查找它。

七、生命週期

Maven有三套相互獨立的生命週期，請注意這裏說的是“三套”，而且“相互獨立”，初學者容易將Maven的生命週期看成一個整體，其實不然。這三套生命週期分別是：

① Clean Lifecycle 在進行真正的構建之前進行一些清理工作。 Clean生命週期一共包含了三個階段：

pre-clean 執行一些需要在clean之前完成的工作
clean 移除所有上一次構建生成的文件
post-clean 執行一些需要在clean之後立刻完成的工作

② Default Lifecycle 構建的核心部分，編譯，測試，打包，部署等等。

validate
generate-sources
process-sources
generate-resources
process-resources 複製並處理資源文件，至目標目錄，準備打包
compile 編譯項目的源代碼
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 複製並處理資源文件，至目標測試目錄
test-compile 編譯測試源代碼
process-test-classes
test 使用合適的單元測試框架運行測試。這些測試代碼不會被打包或部署
prepare-package
package 接受編譯好的代碼，打包成可發佈的格式，如 JAR
pre-integration-test
integration-test
post-integration-test
verify
install 將包安裝至本地倉庫，以讓其它項目依賴。
deploy 將最終的包複製到遠程的倉庫，以讓其它開發人員與項目共享

通過日誌我們發現，其實執行mvn install，其中已經執行了compile 和 test 。

總結： 不論你要執行生命週期的哪一個階段，maven都是從這個生命週期的開始執行

插件： 每個階段都有插件（plugin），看上面標紅的。插件的職責就是執行它對應的命令。

③ Site Lifecycle 生成項目報告，站點，發佈站點。

pre-site 執行一些需要在生成站點文檔之前完成的工作
site 生成項目的站點文檔
post-site 執行一些需要在生成站點文檔之後完成的工作，並且爲部署做準備
site-deploy 將生成的站點文檔部署到特定的服務器上

八、maven工程的依賴高級特性

① 依賴的傳遞性

WebMavenDemo項目依賴JavaMavenService1 JavaMavenService1項目依賴JavaMavenService2

pom.xml文件配置好依賴關係後，必須首先mvn install後，依賴的jar包才能使用。

WebMavenDemo的pom.xml文件想能編譯通過，JavaMavenService1必須mvn install
JavaMavenService的pom.xml文件想能編譯通過，JavaMavenService2必須mvn install

傳遞性：

在Eclipse中，爲JavaMavenService2中增加了一個spring-core.jar包後，會驚喜的發現依賴的兩個項目都自動的增加了這個jar包，這就是依賴的傳遞性。

注意：非compile範圍的依賴是不能傳遞的。

② 依賴版本的原則：

1、路徑最短者優先原則

Service2的log4j的版本是1.2.7版本，Service1排除了此包的依賴，自己加了一個Log4j的1.2.9的版本，那麼WebMavenDemo項目遵守路徑最短優先原則，Log4j的版本和Sercive1的版本一致。

2、路徑相同先聲明優先原則

這種場景依賴關係發生了變化，WebMavenDemo項目依賴Sercive1和Service2，它倆是同一個路徑，那麼誰在WebMavenDemo的pom.xml中先聲明的依賴就用誰的版本。

③ 統一管理依賴的版本：

爲了統一管理版本號，可以使用properties標籤，裏面可以自定義版本的標籤名。在使用的地方使用${自定義標籤名}

十、build配置

<build>
　　<!-- 項目的名字 -->
　　<finalName>WebMavenDemo</finalName>
　　<!-- 描述項目中資源的位置 -->
　　<resources>
　　　　<!-- 自定義資源1 -->
　　　　<resource>
　　　　　　<!-- 資源目錄 -->
　　　　　　<directory>src/main/java</directory>
　　　　　　<!-- 包括哪些文件參與打包 -->
　　　　　　<includes>
　　　　　　　　<include>**/*.xml</include>
　　　　　　</includes>
　　　　　　<!-- 排除哪些文件不參與打包 -->
　　　　　　<excludes>
　　　　　　　　<exclude>**/*.txt</exclude>
　　　　　　　　　　<exclude>**/*.doc</exclude>
　　　　　　</excludes>
　　　　</resource>
　　</resources>
　　<!-- 設置構建時候的插件 -->
　　<plugins>
　　　　<plugin>
　　　　　　<groupId>org.apache.maven.plugins</groupId>
　　　　　　<artifactId>maven-compiler-plugin</artifactId>
　　　　　　<version>2.1</version>
　　　　　　<configuration>
　　　　　　　　<!-- 源代碼編譯版本 -->
　　　　　　　　<source>1.8</source>
　　　　　　　　<!-- 目標平臺編譯版本 -->
　　　　　　　　<target>1.8</target>
　　　　　　</configuration>
　　　　</plugin>
　　　　<!-- 資源插件（資源的插件） -->  
　　　　<plugin>  
　　　　　　<groupId>org.apache.maven.plugins</groupId>  
　　　　　　<artifactId>maven-resources-plugin</artifactId>  
　　　　　　<version>2.1</version>  
　　　　　　<executions>  
　　　　　　　　<execution>  
　　　　　　　　　　<phase>compile</phase>  
　　　　　　　　</execution>  
　　　　　　</executions>  
　　　　　　<configuration>  
　　　　　　　　<encoding>UTF-8</encoding>  
　　　　　　</configuration> 
　　　　</plugin>
　　　　<!-- war插件(將項目打成war包) -->  
　　　　<plugin>  
　　　　　　<groupId>org.apache.maven.plugins</groupId>  
　　　　　　<artifactId>maven-war-plugin</artifactId>  
　　　　　　<version>2.1</version>  
　　　　　　<configuration>
　　　　　　　　<!-- war包名字 -->  
　　　　　　　　<warName>WebMavenDemo1</warName>
　　　　　　</configuration>  
　　　　</plugin>  
　　</plugins>
</build>

配置好build後，執行mvn package之後，在maven工程指定的target目錄裏war包和文件都按照配置的生成了

好了，maven的所有的內容就整理完了。

最後推薦個最新最全的maven依賴項版本查詢網站：

http://mvnrepository.com/

Java項目中常用Maven插件詳解

我們都知道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最全教程，看了必懂

一、爲什麼使用Maven這樣的構建工具【why】

二、maven是什麼【what】

三、安裝maven

四、第一個maven

文件內容如下

五、倉庫和座標

六、依賴

七、生命週期

八、maven工程的依賴高級特性

十、build配置

Java項目中常用Maven插件詳解

使用Redis的bitmaps統計用戶留存率、活躍用戶

MySQL中一條SQL是如何執行的？

MongoDB：快速入門，掌握這些剛剛好！

高併發下的redis擊穿，你需要了解下布隆過濾器

MySQL 優化必經之路， Explain執行計劃？

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結