大話專案管理工具之Maven篇
阿新 • • 發佈：2018-12-20
前言
相信只要做過 Java 開發的童鞋們，對 Ant 想必都不陌生，我們往往使用 Ant 來構建專案，尤其是涉及到特別繁雜的工作量，一個 build.xml 能夠完成編譯、測試、打包、部署等很多工，這在很大的程度上解放了程式設計師們的雙手。但同時也存在一些其他的問題，比如：jar 檔案管理混亂，每次都需要自己去下載；build.xml 因專案結構的不同導致差異性較大。
概況
自從專案中引入 Maven 以後，以前 Ant 能解決的，Maven 提供了更加簡潔的解決方案，而以前 Ant 解決不了的，Maven 也能很好的解決。這就直接導致了專案管理工具的更新換代。當然，這已不是什麼新鮮事了。只不過，一直到現在才有時間來分享專案中使用 Maven 的感受，這一點上，真的很抱歉，後續會及時的更新。
Maven 的入門教程網上已經有很多了，這裡就不再贅述這些基本知識了。還沒有接觸過 Maven 的童鞋，請移步 Google 或 Baidu。之後再回來看這篇文章。在這篇文章裡，我主要結合專案中 Maven 的使用，以及需要注意的事項來與大家討論。
說到 Maven 的原理，其實很簡單，就是採用遠端倉庫和本地倉庫以及一個類似 build.xml 的 pom.xml，將 pom.xml 中定義的 jar 檔案從遠端倉庫下載到本地倉庫，各個應用使用同一個本地倉庫的 jar，同一個版本的 jar 只需下載一次，而且避免每個應用都去拷貝 jar。
同時它採用了現在流行的外掛體系架構，只保留最小的核心，其餘功能都通過外掛的形式提供，所以 Maven 下載很小（1.1M），在執行 Maven 任務時，才會自動下載需要的外掛。而且，Maven 還是跨平臺的，並且提供了支援很多 Java IDE 的擴充套件外掛。在開發中，我們大部分的時間，用到的是 Maven 的外掛。對於公司內部來說，還是需要建立自己的私服的，不過，這裡私服不是重點，就不再討論了。
專案中我們都會根據自己的習慣建立目錄結構，雖然有規範，但難免會有疏漏，長此下去，專案的結構會越來越亂的。Maven 解決了這個問題，對於不同的專案，它提供了多種選擇，並將其作為目錄模板，如下圖所示。
使用目錄模板，可以使pom.xml更簡潔。因為Maven2已經根據預設目錄，預定義了相關的動作，而無需人工的干預。以resources目錄為例：
- src/main/resources，負責管理專案主體的資源。在使用Maven2執行compile之後，這個目錄中的所有檔案及子目錄，會複製到target/classes目錄中，為以後的打包提供了方便。
- src/test/resources，負責管理專案測試的資源。在使用Maven2執行test-compile之後，這個目錄中的所有檔案及子目錄，會複製到target/test-classes目錄中，為後續的測試做好了準備。
這些動作在 Maven1 中，是需要在 maven.xml 中使用<preGoal>或<postGoal>來完成的。如今，完全不需要在pom.xml中指定就能夠自動完成。在src和test都使用resources，方便構建和測試，這種方式本就已是前人的經驗。通過使用Maven2，使這個經驗在開發團隊中得到普及。
生命週期
在 Maven2 中有了明確的生命週期概念，而且都提供與之對應的命令，使得專案構建更加清晰明瞭。主要的生命週期階段：
- validate，驗證工程是否正確，所有需要的資源是否可用。
- verify，執行任何檢查，驗證包是否有效且達到質量標準。
- integration-test，在整合測試可以執行的環境中處理和釋出包。
- generate-sources，產生應用需要的任何額外的原始碼，如xdoclet。
- compile，編譯專案的原始碼。
- test-compile，編譯專案測試程式碼。
- test，使用已編譯的測試程式碼，測試已編譯的原始碼。
- package，已釋出的格式，如jar，將已編譯的原始碼打包。
- install，把包安裝在本地的repository中，可以被其他工程作為依賴來使用。
- deploy，在整合或者釋出環境下執行，將最終版本的包拷貝到遠端的repository，使得其他的開發者或者工程可以共享。
如果要執行專案編譯，那麼直接輸入：mvn compile即可，對於其他的階段可以類推。階段之間是存在依賴關係（dependency）的，如test依賴test-compile。在執行mvn test時，會先執行mvn test-compile，然後才是mvn test。當然，開發中，我們一般都不會直接操作 Maven 的。而是在 Eclipse 中使用 Maven 外掛，其中用的最多的命令就是 clean 、compile 、install 、deploy 等。
依賴
說完生命週期，還有一個必須要說的就是依賴管理了。Maven 中是通過在 pom.xml 中新增依賴從而來引入 jar 包的。其原理是：每一個 jar 都會有獨立的座標，Maven 就是通過座標來定位到具體的 jar 的。
就好像平面座標系一樣，通過 x 軸 和 y 軸定位一個座標點。Maven 定義了這樣一組規則：世界上任何一個構件都可以使用 Maven 座標唯一標識，Maven 座標的元素包括 groupId 、artifactId 、version 、packaging 、classifier 。只要我們提供正確的座標元素，Maven 就能夠找到它。
建議
有的人可能會有疑問，以前沒有 Maven 的時候，我們可以去各自的官網下載 jar，但現在只能通過 pom 引用 jar。那麼如何知道需要新增哪些依賴呢？還有需要什麼版本呢？這也是為什麼有一部分習慣了自己下載 jar，而到了 Maven 這不知道該怎麼用了。
當然，Maven 還不是智慧的，你不可能直接命令 Maven 直接給你找專案所需要的各種元件，或許以後這樣的智慧化的軟體管理工具會出現，至少現在還沒有。因此，還得需要你自己去新增 pom 依賴。至於該如何找，這裡我告訴大家一個方法，雖然方法有點笨，但或許對你快速定位到具體元件有所幫助。
舉個例子，假如現在需要新增 Hibernate 的依賴，但具體哪個版本呢，可以先不用管，直接去 Baidu 或者 Google，以“ maven spring repository ”為關鍵字搜尋，往往第一個連結中，就是你需要的方案。
進入第一連結之後，你會看到這樣一個頁面，搜尋的結果都是關於 Spring 的，根據你的需要，選擇一個連結進入，列表中有各個版本的元件，點選你需要的版本，然後就會看到 Maven 座標。把它複製到你的 pom 檔案中就噢啦。
當然，這只是一種方法，只針對剛接觸 Maven 的童鞋們。隨著專案經驗的增多，以後你就會越來越發現，Maven 解放的不僅僅是你的雙手，還有你最寶貴的時間。
感受
在一個專案中選擇使用一款管理工具是有風險的，那麼該如何把這種風險減到最低，或者讓它轉變為對專案開發有利的一方面呢？這就需要架構師或者專案組長，在專案開始之前進行嚴格的技術考察、技術（工具）選型、學習成本的分析等。
選擇一種技術或者一款工具，不能僅僅因為它的流行程度，還要考慮到本公司開發人員的技術程度，技術（工具）的跨平臺性考慮，擴充套件性與整合性的考慮，以及技術（工具）穩定性的考慮等。當然，對於一種新技術（對開發人員來說是新技術），還需要考慮學習成本，這些都制約日後的開發效率、開發進度，以及出問題後能不能解決等。
所謂的技術選型，並不是選出多麼新的技術，也並不是選出成本最低的技術，而是能夠利用本公司的優勢，找出最適合本公司的技術和工具，在有限的範圍內、有限的時間內把本公司的能力發揮到最大。
就比如，如果在專案管理工具上，公司裡一直都在用 Ant，而且用的也特別的熟練，況且專案的時間特別緊急，公司的開發人員對 Maven 都沒有接觸過，那麼就不用再考慮 Maven 了，因為時間在那擺著呢，而且還有開發人員的學習成本，這種情況下再選擇 Maven，這不是 zuo si 嗎？當然，這種例子不勝列舉，這裡就不再多說了。
結束語
本來應該在最後說的話，都放在了感受裡邊，對於專案管理，還有很多欠缺的，希望在日後的工作中繼續積累經驗吧。當然，也希望大家能夠多交流，共同進步。
【原創】地址：http://blog.csdn.net/happylee6688/article/details/38798669
前言
相信只要做過 Java 開發的童鞋們，對 Ant 想必都不陌生，我們往往使用 Ant 來構建專案，尤其是涉及到特別繁雜的工作量，一個 build.xml 能夠完成編譯、測試、打包、部署等很多工，這在很大的程度上解放了程式設計師們的雙手。但同時也存在一些其他的問題，比如：jar 檔案管理混亂，每次都需要自己去下載；build.xml 因專案結構的不同導致差異性較大。
概況
自從專案中引入 Maven 以後，以前 Ant 能解決的，Maven 提供了更加簡潔的解決方案，而以前 Ant 解決不了的，Maven 也能很好的解決。這就直接導致了專案管理工具的更新換代。當然，這已不是什麼新鮮事了。只不過，一直到現在才有時間來分享專案中使用 Maven 的感受，這一點上，真的很抱歉，後續會及時的更新。
Maven 的入門教程網上已經有很多了，這裡就不再贅述這些基本知識了。還沒有接觸過 Maven 的童鞋，請移步 Google 或 Baidu。之後再回來看這篇文章。在這篇文章裡，我主要結合專案中 Maven 的使用，以及需要注意的事項來與大家討論。
原理
說到 Maven 的原理，其實很簡單，就是採用遠端倉庫和本地倉庫以及一個類似 build.xml 的 pom.xml，將 pom.xml 中定義的 jar 檔案從遠端倉庫下載到本地倉庫，各個應用使用同一個本地倉庫的 jar，同一個版本的 jar 只需下載一次，而且避免每個應用都去拷貝 jar。
同時它採用了現在流行的外掛體系架構，只保留最小的核心，其餘功能都通過外掛的形式提供，所以 Maven 下載很小（1.1M），在執行 Maven 任務時，才會自動下載需要的外掛。而且，Maven 還是跨平臺的，並且提供了支援很多 Java IDE 的擴充套件外掛。在開發中，我們大部分的時間，用到的是 Maven 的外掛。對於公司內部來說，還是需要建立自己的私服的，不過，這裡私服不是重點，就不再討論了。
結構
專案中我們都會根據自己的習慣建立目錄結構，雖然有規範，但難免會有疏漏，長此下去，專案的結構會越來越亂的。Maven 解決了這個問題，對於不同的專案，它提供了多種選擇，並將其作為目錄模板，如下圖所示。
使用目錄模板，可以使pom.xml更簡潔。因為Maven2已經根據預設目錄，預定義了相關的動作，而無需人工的干預。以resources目錄為例：
- src/main/resources，負責管理專案主體的資源。在使用Maven2執行compile之後，這個目錄中的所有檔案及子目錄，會複製到target/classes目錄中，為以後的打包提供了方便。
- src/test/resources，負責管理專案測試的資源。在使用Maven2執行test-compile之後，這個目錄中的所有檔案及子目錄，會複製到target/test-classes目錄中，為後續的測試做好了準備。
這些動作在 Maven1 中，是需要在 maven.xml 中使用<preGoal>或<postGoal>來完成的。如今，完全不需要在pom.xml中指定就能夠自動完成。在src和test都使用resources，方便構建和測試，這種方式本就已是前人的經驗。通過使用Maven2，使這個經驗在開發團隊中得到普及。
生命週期
在 Maven2 中有了明確的生命週期概念，而且都提供與之對應的命令，使得專案構建更加清晰明瞭。主要的生命週期階段：
- validate，驗證工程是否正確，所有需要的資源是否可用。
- verify，執行任何檢查，驗證包是否有效且達到質量標準。
- integration-test，在整合測試可以執行的環境中處理和釋出包。
- generate-sources，產生應用需要的任何額外的原始碼，如xdoclet。
- compile，編譯專案的原始碼。
- test-compile，編譯專案測試程式碼。
- test，使用已編譯的測試程式碼，測試已編譯的原始碼。
- package，已釋出的格式，如jar，將已編譯的原始碼打包。
- install，把包安裝在本地的repository中，可以被其他工程作為依賴來使用。
- deploy，在整合或者釋出環境下執行，將最終版本的包拷貝到遠端的repository，使得其他的開發者或者工程可以共享。
如果要執行專案編譯，那麼直接輸入：mvn compile即可，對於其他的階段可以類推。階段之間是存在依賴關係（dependency）的，如test依賴test-compile。在執行mvn test時，會先執行mvn test-compile，然後才是mvn test。當然，開發中，我們一般都不會直接操作 Maven 的。而是在 Eclipse 中使用 Maven 外掛，其中用的最多的命令就是 clean 、compile 、install 、deploy 等。
依賴
說完生命週期，還有一個必須要說的就是依賴管理了。Maven 中是通過在 pom.xml 中新增依賴從而來引入 jar 包的。其原理是：每一個 jar 都會有獨立的座標，Maven 就是通過座標來定位到具體的 jar 的。
就好像平面座標系一樣，通過 x 軸 和 y 軸定位一個座標點。Maven 定義了這樣一組規則：世界上任何一個構件都可以使用 Maven 座標唯一標識，Maven 座標的元素包括 groupId 、artifactId 、version 、packaging 、classifier 。只要我們提供正確的座標元素，Maven 就能夠找到它。
建議
有的人可能會有疑問，以前沒有 Maven 的時候，我們可以去各自的官網下載 jar，但現在只能通過 pom 引用 jar。那麼如何知道需要新增哪些依賴呢？還有需要什麼版本呢？這也是為什麼有一部分習慣了自己下載 jar，而到了 Maven 這不知道該怎麼用了。
當然，Maven 還不是智慧的，你不可能直接命令 Maven 直接給你找專案所需要的各種元件，或許以後這樣的智慧化的軟體管理工具會出現，至少現在還沒有。因此，還得需要你自己去新增 pom 依賴。至於該如何找，這裡我告訴大家一個方法，雖然方法有點笨，但或許對你快速定位到具體元件有所幫助。
舉個例子，假如現在需要新增 Hibernate 的依賴，但具體哪個版本呢，可以先不用管，直接去 Baidu 或者 Google，以“ maven spring repository ”為關鍵字搜尋，往往第一個連結中，就是你需要的方案。
進入第一連結之後，你會看到這樣一個頁面，搜尋的結果都是關於 Spring 的，根據你的需要，選擇一個連結進入，列表中有各個版本的元件，點選你需要的版本，然後就會看到 Maven 座標。把它複製到你的 pom 檔案中就噢啦。
當然，這只是一種方法，只針對剛接觸 Maven 的童鞋們。隨著專案經驗的增多，以後你就會越來越發現，Maven 解放的不僅僅是你的雙手，還有你最寶貴的時間。
感受
在一個專案中選擇使用一款管理工具是有風險的，那麼該如何把這種風險減到最低，或者讓它轉變為對專案開發有利的一方面呢？這就需要架構師或者專案組長，在專案開始之前進行嚴格的技術考察、技術（工具）選型、學習成本的分析等。
選擇一種技術或者一款工具，不能僅僅因為它的流行程度，還要考慮到本公司開發人員的技術程度，技術（工具）的跨平臺性考慮，擴充套件性與整合性的考慮，以及技術（工具）穩定性的考慮等。當然，對於一種新技術（對開發人員來說是新技術），還需要考慮學習成本，這些都制約日後的開發效率、開發進度，以及出問題後能不能解決等。
所謂的技術選型，並不是選出多麼新的技術，也並不是選出成本最低的技術，而是能夠利用本公司的優勢，找出最適合本公司的技術和工具，在有限的範圍內、有限的時間內把本公司的能力發揮到最大。
就比如，如果在專案管理工具上，公司裡一直都在用 Ant，而且用的也特別的熟練，況且專案的時間特別緊急，公司的開發人員對 Maven 都沒有接觸過，那麼就不用再考慮 Maven 了，因為時間在那擺著呢，而且還有開發人員的學習成本，這種情況下再選擇 Maven，這不是 zuo si 嗎？當然，這種例子不勝列舉，這裡就不再多說了。
結束語
本來應該在最後說的話，都放在了感受裡邊，對於專案管理，還有很多欠缺的，希望在日後的工作中繼續積累經驗吧。當然，也希望大家能夠多交流，共同進步。
【原創】地址：http://blog.csdn.net/happylee6688/article/details/38798669