Maven(一)定義與設計原則

ApacheMaven:

[本系列博客是參照中文文檔的總結,文檔下載地址:(http://download.csdn.net/download/u012160163/9787289)

定義:

Maven是一個項目管理工具,它包含了一個項目對象模型 (Project Object Model),一組標準集合,一個項目生命週期(ProjectLifecycle),一個依賴管理系統(Dependency Management System),和用來運行定義在生命週期階段(phase)中插件(plugin)目標(goal)的邏輯。 當你使用Maven的時候,你用一個明確定義的項目對象模型來描述你的項目,然後 Maven 可以應用橫切的邏輯,這些邏輯來自一組共享的(或者自定義的)插件。

設計原則:

(1)約定優於配置(Convention Over Configuration)

Maven通過給項目提供明智的默認行爲來融合這個概念.
默認目錄
在沒有自定義的情況下,(basepath=/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/content-zh)
源代碼假定是在: basepath/src/main/java ,
資源文件假定是在: basepath/src/main/resources。
測試代碼假定是在: basepath/src/test 。
項目假定會產生一個 JAR 文件。
編譯好的字節碼假定放到: basepath/target/classes
並且在basepath/target 創建一個可分發的 JAR 文件。
一個定義好的生命週期和一組知道如何構建和裝配軟件的通用插件
Maven 對約定優於配置的應用不僅僅是簡單的目錄位置,Maven 的核心插件使用了一組通用的約定,以用來編譯源代碼,打包可分發的構件,生成 web 站點,還有許多其他的過程。 Maven 的力量來自它的”武斷”,它有一個定義好的生命週期和一組知道如何構建和裝配軟件的通用插件。如果遵循這些約定,Maven 只需要幾乎爲零的工作——僅僅是將你的源代碼放到正確的目錄,Maven 將會幫你處理剩下的事情。
注意
使用“遵循約定優於配置”系統的一個副作用是用戶可能會覺得他們被強迫使用一種特殊的方法。 當然 Maven 有一些核心觀點不應該被懷疑,但是其實很多默認行爲還是可配置的。 例如項目源碼的資源文件的位置可以被自定義,JAR 文件的名字可以被自定義,在開發自定義插件的時候,幾乎任何行爲可以被裁剪以滿足你特定的環境需求。如果你不想遵循約定,Maven 也會允許你自定義默認值來適應你的需求。

(2)定義一個夠將軟件一般的接口

現在,大部分開源開發者已經或者正在使用 Maven 來管理他們新的軟件項目。這種轉變不僅僅是開發人員從一種構建工具轉移到另外一種構建工具,更是開發人員開始爲他們的項目採用一種一般的接口。隨着軟件系統變得越來越模塊化,構建系統變得更復雜,而項目的數量更是如火箭般飛速上升。在 Maven 之前,當你想要從 Subversion簽出一個項目如 Apache ActiveMQ 5 或 Apache ServiceMix 6 ,然後從源碼進行構建,你需要爲每個項目留出一個小時來理解給它的構建系統。這個項目需要構建什麼?需要現在什麼類庫?把類庫放哪裏?構建中我該運行什麼目標?最好的情況下,理解一個新項目的構建需要幾分鐘,最壞的情況下(例如 Jakarta 項目的舊的 Servlet API 實現),一個項目的構建特別的困難,以至於花了幾個小時以後,新的貢獻者也只能編輯源碼和編譯項目。現在,你只要簽出源碼,然後運行: mvn install 。雖然 Maven 有很多優點,包括依賴管理和通過插件重用一般的構建邏輯,但它成功的最核心原因是*它定義了構建軟件的一般的接口。每當你看到一個使用 Maven 的項目,你就可以假設你能簽出它的源碼然後使用 mvn install 構建它,沒什麼好爭論的。

(3)基於Maven插件的全局性重用:

Maven 的核心其實不做什麼實際的事情,除了解析一些 XML 文檔管理生命週期與插件之外,它什麼也不懂。Maven 被設計成將主要的職責委派給一組 Maven 插件,這些插件可以影響 Maven 生命週期,提供對目標的訪問。
絕大多數 Maven 的動作發生於Maven 插件的目標,如編譯源碼,打包二進制代碼,發佈站點和其它構建任務。你從Apache 下載的 Maven 不知道如何打包 WAR 文件,也不知道如何運行單元測試,Maven大部分的智能是由插件實現的,而插件從 Maven 倉庫獲得。事實上,第一次你用全新的 Maven 安裝運行諸如 mvn install 命令的時候,它會從中央 Maven 倉庫下載大部分核心 Maven 插件。這不僅僅是一個最小化 Maven 分發包大小的技巧,這種方式更能讓你升級插件以給你項目的構建提高能力。Maven 從遠程倉庫獲取依賴和插件的這一事實允許了構建邏輯的全局性重用
例如Maven Surefire 插件是負責運行單元測試的插件。從版本 1.0 發展到目前廣泛使用的在 JUnit 基礎上增加了 TestNG 測試框架支持的版本。這種發展並沒有破壞向後兼容性,如果你使用之前 Surefire 插件編譯運行你的 JUnit 3 單元測試,然後你升級到了最新版本的 Surefire 插件,你的測試仍然能成功運行。但是,我們又獲得了新的功能,如果你想使用 TestNG 運行單元測試,那麼感謝 Surefire 插件的維護者,你已經可以使用 TestNG 了。你也能運行支持註解的 JUnit 4 單元測試。不用升級 Maven 安裝或者新裝任何軟件,你就能獲得這些功能。更重要的是,除了 POM 中一個插件的版本號,你不需要更改你項目的任何東西

(4)一個“項目”的概念模型:

Maven 維護了一個項目的模型,你不僅僅需要把源碼編譯成字節碼,你還需要開發軟件項目的描述信息,爲項目指定一組唯一的座標。你要描述項目的的屬性。項目的許可證是什麼?誰開發這個項目,爲這個項目做貢獻?這個項目依賴於其它什麼項目沒有?Maven不僅僅是一個“構建工具”,它不僅僅是在類似於 make 和 Ant 的工具的基礎上的改進,它是包含了一組關於軟件項目和軟件開發的語義規則的平臺。這個基於每一個項目定義的模型實現瞭如下特徵

依賴管理:

由於項目是根據一個包含組標識符,構件標識符和版本的唯一的座標定義的。項目間可以使用這些座標來聲明依賴

遠程倉庫:

和項目依賴相關的,我們可以使用定義在項目對象模型(POM)中的座標來創建Maven 構件的倉庫。

全局性構建邏輯重用:

插件被編寫成和項目模型對象(POM)一起工作,它們沒有被設計成操作某一個已知位置的特定文件。一切都被抽象到模型中,插件配置和自定義行爲都在模型中進行。

工具可移植性/集成:

像 Eclipse,NetBeans,和 InteliJ 這樣的工具現在有共同的地方來找到項目的信息。在 Maven 出現之前,每個 IDE 都有不同的方法來存儲實際上是自定義項目對象模型(POM)的信息。Maven 標準化了這種描述,而雖然每個 IDE 仍然繼續維護它的自定義項目文件,但這些文件現在可以很容易的由模型生成。

便於搜索和過濾構件:

像 Nexus 這樣的工具允許你使用存儲在 POM 中的信息對倉庫中的內容進行索引和搜索。

Maven 爲軟件項目的語義一致性描述的開端提供了一個基礎。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章