Maven

Maven

Maven項目對象模型(POM)，能夠經過一小段描述信息來管理項目的構建，報告和文檔的項目管理工具軟件。

Maven 除了以程序構建能力爲特點以外，還提供高級項目管理工具。因爲 Maven 的缺省構建規則有較高的可重用性，因此經常用兩三行 Maven 構建腳本就能夠構建簡單的項目。因爲 Maven 的面向項目的方法，許多 Apache Jakarta 項目發文時使用 Maven，並且公司項目採用 Maven 的比例在持續增加。

Maven這個單詞來自於意第緒語（猶太語），意爲知識的積累，最初在Jakata Turbine項目中用來簡化構建過程。當時有一些項目（有各自Ant build文件），僅有細微的差異，而JAR文件都由CVS來維護。因而但願有一種標準化的方式構建項目，一個清晰的方式定義項目的組成，一個容易的方式發佈項目的信息，以及一種簡單的方式在多個項目中共享JARs。

maven的優勢

1．依賴的管理

Maven是如何找jar包的？

說白了，其實就是對jar 包的管理並給出座標的過程。

2．一鍵構建

什麼是構建？

指的是項目從編譯-----測試-----運行----打包-------安裝整個過程都交給maven進行管理，這個過程稱爲構建。

Maven命令

1．clean

clean是maven工程的清理命令，執行

clean會刪除target目錄及其目錄下全部內容

2．Compile

compile是maven工程的編譯命令，做用是將src/main/java下的java源文件編譯爲class文件並輸出到target下的classes目錄下。

cmd進入命令狀態，執行mvn compile，以下圖提示成功：

查看 target目錄classes下，class文件已生成，編譯完成

3．test

test是maven工程的測試命令 mvn test,會執行src/test/java下的單元測試類。

cmd執行mvn test執行src/test/java下單元測試類,下圖爲測試結果,運行1個測試用例,所有成功。

4．package

package是maven工程的打包命令, 對於java工程執行package打成jar包,對於web工程打成war包

工程目錄下執行 mvn

package

5．Install

install是maven工程的安裝命令，執行install將maven打成jar包或war包發佈到本地倉庫

從運行結果中，能夠看出：

當後面的命令執行時，前面的操做過程也都會自動執行

在cmd中的命令：

a. mvn eclipse:clean 清除Project中之前的編譯的東西，從新再來

b. mvn eclipse:eclipse 開始編譯Maven的Project

在eclipse中的操做：

a. 選中Maven Project 右擊 在Run As中選擇Maven clean

b. 在Myeclipse中，Project—Clean 開始編譯

c. 選中Maven Project 右擊 在Run As中選擇Maven install

執行完這幾步，若是沒發生異常，會在project裏生成一個target文件夾，這個文件夾裏的東西，就是Maven打包發佈的東西。

mvn archetype:generate 建立Maven項目
mvn compile 編譯源代碼
mvn deploy 發佈項目
mvn test-compile 編譯測試源代碼
mvn test 運行應用程序中的單元測試
mvn site 生成項目相關信息的網站
mvn clean 清除項目目錄中的生成結果
mvn package 根據項目生成的jar
mvn install 在本地Repository中安裝jar
mvn eclipse:eclipse 生成eclipse項目文件
mvnjetty:run 啓動jetty服務
mvntomcat:run 啓動tomcat服務
mvn clean package -Dmaven.test.skip=true:清除之前的包後從新打包，跳過測試類

三套生命週期

Maven對項目構建過程分爲三套相互獨立的生命週期，請注意這裏說的是「三套」，並且「相互獨立」，這三套生命週期分別是：

\1. Clean Lifecycle: 在進行真正的構建以前進行一些清理工做。

\2. Default Lifecycle: 構建的核心部分：編譯、測試、打包、部署等等。

\3. Site Lifecycle: 生成項目報告、站點、發佈站點。

每個階段都有一個對應的命令，且有相應的插件來支持命令的運行。

注：屬於同一個指令週期內的指令，當後面的命令執行時，前面的命令會自動執行。

Jar包的做用範圍scope屬性

添加jar包的座標時，還能夠指定這個jar包未來的做用範圍

依賴範圍包括

compile：編譯範圍，批A在編譯時依賴B，此範圍爲默認依賴範圍。編譯範圍的依賴會用在編譯、測試、運行，因爲運行時須要因此編譯範圍的依賴會被打包。

provided：provided依賴只有在當JDK或者一個容器已提供該依賴以後才使用，provided依賴在編譯和測試時須要，在運行時不須要，好比：servlet api被tomcat容器提供。

runtime: runtime依賴在運行和測試系統時候須要，但在編譯的時候不須要，好比：jdbc的驅動包。因爲運行時須要，因此runtime範圍的依賴會被打包

test：test範圍依賴在編譯和運行時都不須要，它們只有在測試編譯和測試運行階段可用，好比：junit。因爲運行時不須要，因此test範圍依賴不會被打包。

system：system範圍依賴與provided相似，可是你必須顯式的提供一個對於本地系統中jar文件的路徑，須要指定systemPath磁盤路徑，system依賴不推薦使用。

修改pom.xml，給這兩個座標都加上scope爲provided 以下：

標準目錄佈局簡介

擁有一個通用的目錄佈局將容許熟悉一個Maven項目的用戶當即在另外一個Maven項目中感到賓至如歸。優勢相似於採用站點範圍的外觀。

下一節將介紹Maven所指望的目錄佈局以及Maven建立的目錄佈局。請儘可能遵照這種結構; 可是，若是您不能經過項目描述符覆蓋這些設置。

src/main/java	應用程序/庫源
src/main/resources	應用程序/庫資源
src/main/filters	資源過濾文件
src/main/webapp	Web應用程序源
src/test/java	測試來源
src/test/resources	測試資源
src/test/filters	測試資源過濾器文件
src/it	集成測試（主要用於插件）
src/assembly	程序集描述符
src/site	現場
LICENSE.TXT	項目許可證
NOTICE.txt	項目所依賴的圖書館所需的通知和歸屬
README.txt	項目自述

的src / main /資源在頂層，描述項目的文件：pom.xml文件。此外，還有一些文本文檔供用戶在接收源時當即讀取：README.txt，LICENSE.txt等。

這個結構只有兩個子目錄：src和target。這裏預期的惟一其餘目錄是CVS，.git或.svn等元數據，以及多項目構建中的任何子項目（每一個子項目都將按上面的方式佈局）。

在目標目錄用於容納生成的全部輸出。

該SRC目錄包含了全部的源材料的建設項目，其網站等等。它包含每種類型的子目錄：main用於主構建工件，測試單元測試代碼和資源，站點等。

在工件生成源目錄（即main和test）中，有一個用於語言java的目錄（在其下存在正常的包層次結構），還有一個用於資源（在給定默認資源定義的狀況下複製到目標類路徑的結構） ）。

若是工件構建還有其餘貢獻源，則它們將位於其餘子目錄下：例如，src / main / antlr將包含Antlr語法定義文件。

Maven工程的拆分與聚合

工程的拆分

爲何要拆分？

面對當今互聯網+的行業，軟件項目變得愈來愈龐大，複雜程度愈來愈高，ddd提升了開發與管理的成本。工程的拆分能夠實現分模塊開發與測試，可實現多線程開發與管理，提升工程代碼複用度的同時也提升軟件的開發速度與效率。

一個完整的早期開發好的crm項目，如今要使用maven工程對它進行拆分，這時候就能夠將dao拆解出來，造成獨立的工程，一樣service,action也都進行這樣的拆分

把工程拆分紅獨立的工程，未來要用到的時候就把它們的座標給引進來就好了，這就有點相似於搭積木同樣

工程的聚合

咱們的crm項目拆成多個子模塊後，獨立運行各個模塊是沒法完成軟件項目的要求的，只有把它們都整合起來，分工合做才能完成工做。所以須要父工程來管理各個子模塊，把它們聚合在一塊兒運行，把crm06_dao, crm06_service, crm06_web打成一個獨立的可運行的war包。

好比：把汽車的各個零部件組裝成起來，變成一輛能夠行駛的車

繼承的理解

相似java類的繼承，都是爲了消除重複。子類繼承父類，父類裏有的方法和屬性在子類中就不須要再定義和實現了，使用的時候直接調用父類就能夠。咱們把crm拆分後，有一個父工程，子工程(crm06_dao,crm06_service, crm06_web)要用到的依賴均可以在父工程(crm06)的pom.xml先定義好，未來子工程在開發的時候就不須要再引座標了。

爲了達到聚合的目標，因此今天會引入

父工程（maven project）

子模塊(maven module) dao, service, web

依賴關係

1．添加模塊之間的依賴關係

1. Service依賴於dao

咱們的crm06_service未來要把數據存儲到數據庫，須要依賴crm06_dao，須要在crm06_service的pom.xml中添加crm06_dao的依賴，即添加crm06_dao的工程座標

保存後查看pom.xml的變化，dependencies下添加了crm06_dao工程的座標

查看工程左右顯示的Maven Dependencies

2. Web action依賴於service

同理，crm06_web模塊須要調用業務，就須要添加crm06_service的依賴，須要在crm06_web的pom.xml中添加crm06_service的工程座標

方法同上

2．依賴具備傳遞性

查看crm06_web左邊工程顯示maven dependencies，此時能夠看到：把crm06_dao也依賴進來了，這是由於：依賴具備傳遞性

3．依賴傳遞也是有範圍的（瞭解）

子模塊crm06_dao中添加junit的依賴，scope爲test，但在crm06_service中並不能使用junit

一、縱座標：直接依賴

A 依賴 B，B 是 A 的直接依賴。

在

A 的 pom.xml 中添加 B 的座標。

二、橫座標：傳遞依賴

B 依賴 C，C 是 A 的傳遞依賴。

三、中間部分：傳遞依賴的範圍，A 依賴 C 的範圍。

依賴衝突解決方法：

若是在依賴傳遞過程當中，致使jar包丟失，咱們的作法很簡單，就是再導入一次座標

衝突問題的解決

1．經過添加標籤來解決衝突

在父工程中引入了struts-core,hibernate-core，就發現jar包是有衝突的Javassist存在版本上衝突問題

進入下圖：

背後的父工程的pom.xml文件中，添加的內容

2．依賴調解的原則

1. 第一聲明者優先原則

誰先申明，就用誰的。跟座標代碼的順序有關

測試：

添加struts2-spring-plugin(2.3.24)在前，spring-context(4.2.3.RELEASE)在後。

結果

若是將上邊struts-spring-plugins和spring-context順序顛倒，系統將導入spring-beans-4.2.3。

結果：

分析：

因爲spring-context在前邊以spring-context依賴的spring-beans-4.2.3爲準，因此最終spring-beans-4.2.3添加到了工程中。

2. 路徑近者優先原則

struts2-spring-plugin(2.3.24)跟spring-context(4.2.3.RELEASE)都會添加spring-beans的依賴。Strut2-spring-plugin會引入spring-beans.3.0.5, 而spring-context會引入spring-beans.4.2.3。若是這時咱們直接加入新的依賴叫spring-beans.4.2.4.RELEASE

結果：

分析：系統中若是要引入spring-beans，能夠有如下方法

Ø 經過引入struts2-spring-plugin，它會引入spring-beans.3.0.5的版本。須要通過的路徑爲2個節點

Ø 經過引入srping-beans-4.2.3，它會引入spring-beans.4.2.3的版本，須要通過的路徑爲2個節點

Ø 若是直接引入spring-beans-4.2.4，只須要通過1個節點

所以無論spring-beans.4.2.4的位置在哪，系統始終都是引入spring-beans.4.2.4的版本。

3．使用版本鎖定實現衝突解決

1. 使用dependencyManagement父工程鎖定

首先父工程中pom.xml文件添加：

子工程中的pom.xml文件添加junit座標時就不須要版本的信息了：

2. 定義版本常量

在使用座標時，對於同一個框架，引入屢次時，它的版本信息就會屢次出現，因此能夠借用常量的思想，將這些版本號提取出來，在須要用到的時候，直接寫版本的常量名稱就能夠了。

引用上面的常量