maven的概念模型
Maven是Apache下的一個開源項目，它是一個項目管理工具，它用於對java項目進行項目構建、依賴管理及項目信息管理。當前使用Maven的項目在持續增長。
Maven包含了一個項目對象模型 (Project Object Model)，一組標準集合，一個項目生命週期(Project Lifecycle)，一個依賴管理系統(Dependency Management System)，和用來運行定義在生命週期階段(phase)中插件(plugin)目標(goal)的邏輯。
1.Pom項目對象模型
創建一個maven項目，每一個maven項目中都有一個pom.xml文件，在這個文件中我們就可以配置相關信息
2.依賴管理
通過定義項目所依賴組件的座標由maven進行依賴管理。
比如：項目依賴struts2.3.24，通過在pom.xml中定義依賴即可將struts2的jar包自動加入工程：
3.maven項目生命週期
Maven倉庫
關於倉庫的種類:
1.本地倉庫
由我們自己配置的一個倉庫，從遠程倉庫中下載下的jar，都會存儲到本地倉庫中。
2.遠程倉庫
網絡上的其它倉庫
3.中央倉庫:
在maven環境內部內置一個遠程倉庫地址http://repo1.maven.org/maven2 ，它是中央倉庫，服務於整個互聯網，它是由Maven自己維護，裏面有大量的常用類庫，幷包含了世界上大部分流行的開源項目構件。它本身也是一個遠程倉庫，因爲它是由maven團隊維護
Maven安裝配置
下載網址： http://maven.apache.org/download.cgi
本教程使用3.1.1 版本
解壓不含有中文和空格的目錄
bin目錄 mvn.bat （以run方式運行項目）、 mvnDebug.bat（以debug方式運行項目 ）
boot目錄 maven運行需要類加載器
conf目錄 settings.xml 整個maven工具核心配置文件
lib目錄 maven運行依賴jar包
環境變量配置
電腦上 安裝JDK1.4 + 版本 （將JAVA_HOME/bin 配置環境變量path ）
1.在環境變量中創建一個MAVEN_HOME配置的是D:\apache-maven-3.3.9
2.在環境變量中path配置 %MAVEN_HOME%\bin
將 %MAVEN_HOME%\bin 加入環境變量 path
通過 mvn -v命令檢查 配置是否成功
Maven倉庫配置(本地倉庫)
本地倉庫是用來存放聯網下載maven的插件和jar包，maven本地倉庫有的jar不再從互聯網下載，所以本地倉庫相當於一個緩存。
本地倉庫有一個默認位置：${user.dir}/.m2/repository，${user.dir}表示windows用戶目錄，如下
全局本地倉庫:
我們在maven目錄下的conf下的setttings.xml文件中配置的就是一個全局的本地倉庫
局部本地倉庫:
可以將settings.xml文件複製到指定的目錄下，來進行配置，它就是一個局部的。
注意:如何在settings.xml文件中指定倉庫位置：
Eclipse整合maven
當前的eclipse的版本是Mars.2 Release (4.5.2),此版本自帶maven插件不用單獨安裝。
指定settings.xml文件
注意：如果修改了 setting.xml點擊上圖片的“update settings”，對本地倉庫重建索引，點擊“Reindex”。指定它，會幫助我們重建索引。
當我們重建索引後，後續在pom.xml文件中引入依賴，就會爲我們添加提示。
在eclipse中瀏覽倉庫
Maven命令介紹
這些命令都是通過插件方式來使用的。
執行編譯命令compile，在eclipse中可以省略mvn,cmd下要加上mvn compile
編譯後 .class文件在 target/classes 下 （這個命令只會對java源程序編譯， 不會編譯測試代碼 ， 編譯測試類 mvn test-compile , 編譯後.class 文件在 target\test-classes ）
執行清空命令clean，清空target下的編譯好的文件包括打好的包。
Mvn test命令，編譯test包下的文件到target目錄。
Package命令，將項目打包到target下，默認生成jar包名稱 ： artifactId-version.jar java項目生成 jar包， web項目生成war包
Install命令：將項目jar或war打包發佈到倉庫---- 安裝到倉庫/groupId/artifactId/version 目錄
測試命令 mvn test 執行所有測試用例方法， 重新編譯
在實際開發中，一般都是在eclipse中來執行maven的命令，我們也可以在命令行執行。
Run as 採用 mvn 命令運行 ，Debug as 採用 mvnDebug 命令調試方式運行（可打斷點）
如:maven clean maven install maven test可以直接執行
maven命令在命令行下執行
Mvn命令在命令行執行，前提必須定位到pom.xml文件所在的路徑下執行需要加mvn,eclipse中不需要加。
maven項目生命週期
Maven clean maven compile maven test……
Maven有三套相互獨立的生命週期這三套生命週期分別是：
Clean Lifecycle 在進行真正的構建之前進行一些清理工作。
Default Lifecycle 構建的核心部分，編譯，測試，打包，部署等等。
Site Lifecycle 生成項目報告，站點，發佈站點。
執行後邊的生命週期命令，前邊的會自動執行，比如執行package 上面的命令都會自動執行。
1、生命週期clean
clean生命週期每套生命週期都由一組階段(Phase)組成，我們平時在命令行輸入的命令總會對應於一個特定的階段。比如，運行mvn clean ，這個的clean是Clean生命週期的一個階段。有Clean生命週期，也有clean階段。Clean生命週期一共包含了三個階段：
pre-clean 執行一些需要在clean之前完成的工作
clean 移除所有上一次構建生成的文件
post-clean 執行一些需要在clean之後立刻完成的工作
mvn clean 中的clean就是上面的clean，在一個生命週期中，運行某個階段的時候，它之前的所有階段都會被運行，也就是說，mvn clean 等同於 mvn pre-clean clean ，如果我們運行 mvn post-clean ，那麼 pre-clean，clean 都會被運行。這是Maven很重要的一個規則，可以大大簡化命令行的輸入。
2、生命週期default
Default生命週期Default生命週期是Maven生命週期中最重要的一個，絕大部分工作都發生在這個生命週期中：
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 將最終的包複製到遠程的倉庫，以讓其它開發人員與項目共享。
3、生命週期site
Site生命週期pre-site 執行一些需要在生成站點文檔之前完成的工作
site 生成項目的站點文檔
post-site 執行一些需要在生成站點文檔之後完成的工作，並且爲部署做準備
site-deploy 將生成的站點文檔部署到特定的服務器上
這裏經常用到的是site階段和site-deploy階段，用以生成和發佈Maven站點，這可是Maven相當強大的功能，Manager比較喜歡，文檔及統計數據自動生成，很好看。
Pom.xml配置文件詳解
pom.xml是Maven項目的核心配置文件，位於每個工程的根目錄，基本配置如下：
<project > ：文件的根節點 .
<modelversion > ： pom.xml使用的對象模型版本(可以理解爲約束的版本) .
<groupId > ：項目名稱，一般寫項目的域名
<artifactId > ：模塊名稱，子項目名或模塊名稱
<version > ：產品的版本號 .
<packaging > ：打包類型，一般有jar、war、pom 等
<name > ：項目的顯示名，常用於 Maven 生成的文檔。
<description > ：項目描述，常用於 Maven 生成的文檔
<dependencies> ：項目依賴構件配置，配置項目依賴構件的座標
<build> ：項目構建配置，配置編譯、運行插件等。
第一部分： POM Relationships 關係
Coordinates 座標： 在倉庫中唯一標識項目位置三個參數
<groupId> 項目名稱
<artifactId> 模塊名稱
<version> 版本號
Aggregation 聚合（多模塊） ： 將項目分解爲多個不同模塊
Inheritance 繼承 ： 項目之間繼承，實現POM複用
Dependencies 依賴： 項目依賴另一個項目進行編譯或者運行
第二部分： Project Information 項目信息
name ：項目名稱
desciption： 項目描述
第三部分： Build settings 構建配置
properties ： 配置屬性
build ：構建項目需要插件配置
packaging ：打包方式 jar、war、pom （使用繼承）
reporting ： 報表
第四部分： Build Environment 構建環境 （在依賴、構建、運行 生效配置 ）
Distribution Management ：版本鎖定
Profile ： 靈活自定義配置，在特定情況激活
工程默認編碼
關於maven的tomcat插件使用
可以手動配置端口：maven tomcat插件配置端口
如果使用的tomcat7，可以按如下方案:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
</plugin>
在eclipse中運行,使用 tomcat7:run就可以
如果使用的是tomcat6,可以按如下方案:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.1</version>
</plugin>
運行:tomcat:run
可以同時添加倆個tomcat插件(7\6)
finalname：配置生成的war文件名稱maven_ssh
添加依賴
在pom.xml中定義dependency標籤，導入依賴
通過eclipse導入：
查找座標
方法一：使用網站搜索
http://search.maven.org/
http://mvnrepository.com/
網站搜索示例：
方法二：使用maven插件的索引功能
依賴範圍scope
所謂的依賴範圍，是指我們導入的jar包它的生命週期,簡單說，就是它在什麼情況下可有效
默認：compile
compile：編譯範圍，指A在編譯時依賴B，此範圍爲默認依賴範圍。編譯範圍的依賴會用在編譯、測試、運行，由於運行時需要所以編譯範圍的依賴會被打包。
provided：provided依賴只有在當JDK或者一個容器已提供該依賴之後才使用， provided依賴在編譯和測試時需要，在運行時不需要，比如：servlet api被tomcat容器提供。
runtime：runtime依賴在運行和測試系統的時候需要，但在編譯的時候不需要。比如：jdbc的驅動包。由於運行時需要所以runtime範圍的依賴會被打包。
test：test範圍依賴 在編譯和運行時都不需要，它們只有在測試編譯和測試運行階段可用，比如：junit。由於運行時不需要所以test範圍依賴不會被打包。
system：system範圍依賴與provided類似，但是你必須顯式的提供一個對於本地系統中JAR文件的路徑，需要指定systemPath磁盤路徑，system依賴不推薦使用。
測試總結：
默認引入 的jar包 ------- compile 【默認範圍 可以不寫】（編譯、測試、運行 都有效 ）
servlet-api 、jsp-api ------- provided （編譯、測試 有效， 運行時無效 防止和tomcat下jar衝突）
jdbc驅動jar包 ---- runtime （測試、運行 有效 ）
junit ----- test （測試有效）
依賴範圍由強到弱的順序是：compile>provided>runtime>test
依賴傳遞
A 依賴B、B依賴C，在A中導入B後會自動導入C，C是A的傳遞依賴，如果C依賴D則D也是A的傳遞依賴。爲什麼會出現這種情況，原因在依賴的jar包對應的pom文件中還有依賴的聲明。
依賴傳遞範圍
簡單說，通過依賴傳遞的範圍就可以解決是否要導入依賴的jar包。
縱列：項目A依賴於B的範圍。
橫列：項目B依賴於C的範圍。
框中結果即得出A依賴於C的範圍。
依賴版本衝突問題解決
<!-- struts2-spring-plugin依賴spirng-beans-3.0.5 -->
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-spring-plugin</artifactId>
<version>2.3.24</version>
</dependency>
<!-- spring-context依賴spring-beans-4.2.4 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.2.4.RELEASE</version>
</dependency>
org.apache.struts依賴spirng-beans-3.0.5，spring-context依賴spring-beans-4.2.4，但是發現spirng-beans-3.0.5加入到工程中，而我們希望spring-beans-4.2.4加入工程。
maven自動按照下邊的原則調解依賴標準:
1.第一聲明者優先原則
在pom文件中誰先聲明以誰爲準。
2.路徑近者優先原則
例如：A-> spirng-beans-4.2.4，A->B-> spirng-beans-3.0.5，則spirng-beans-4.2.4優先
解決方案:
1、排除依賴(開發中應用比較少)
2、鎖定版本(推薦使用)
面對衆多的依賴，有一種方法不用考慮依賴路徑、聲明優化等因素可以採用直接鎖定版本的方法確定依賴構件的版本，此方法在企業開發中常用：
Pom中查看標籤位置規則
在project上點擊f2
