為什么要有依賴管理工具?

　　談依賴管理之前，我們先談談為什么要有依賴管理工具這東西。

　　我們學了一種編程語言，然后寫了個“Hello World”，然后宣稱自己學了一門語言，這時候確實不需要關心依賴問題。

　　然而，當你要寫一個稍微復雜點的應用，那怕就是留言板這樣的，需要讀寫數據庫，就需要依賴數據庫驅動，就會遇到依賴管理的問題了。

　　再進一步，你寫了一個庫，想共享給別人使用，更需要了解依賴管理的問題。

　　當然，如果項目足夠簡單，你可以直接將依賴方的源碼放置在自己的項目中，或者將依賴庫的二進制文件(比如jar，dll)放置在項目的lib里。要提供給別人呢?把二進制包提供下載或者給別人傳過去。依賴管理工具出現之前大多數都是這樣搞的。

　　但如果再復雜些，依賴庫本身也有依賴怎么弄呢?將依賴壓縮打包，然后放個readme幫助文件說明下，貌似也可以工作。

　　那如果你的項目依賴了好幾個，乃至幾十個庫，而各庫又有依賴，依賴也有自己的依賴，怎么辦?怎么檢測庫的依賴是否有版本沖突?以后升級的時候怎么辦?怎么判斷lib目錄下的某個文件是否被依賴了?

　　到這一步必須要承認需要有個依賴管理工具了，無論你使用任何語言。我們大約也清楚了依賴管理要做些什么。假設還沒有依賴管理工具，我們自己要設計一個，如何入手?

　　1.要有一種依賴庫的命名規則，或者叫坐標(Coordinates)的定義規則，可以通過坐標準確找到依賴的庫。

　　2.要有對應的配置文件規則，來描述和定義依賴。

　　3.要有中心倉庫保存這些依賴庫，以及依賴庫的元數據(metadata)，供使用方拉取。

　　4.還需要一個本地工具去解析這個配置文件，實現依賴的拉取。

　　以上其實就是各依賴管理工具的核心要素。

　　聊聊Maven

　　Maven誕生于2004年(來源維基)，查詢了下，應該是各語言的依賴管理工具中早的。Ruby的gem也是2004年出現的，但gem離完備的依賴管理工具還差些，直到Ruby的bundler出現。Python的pip出現的更晚。

　　Maven的習慣是通過 groupID(一般是組織的域名倒寫，遵循Java package的命名習慣)+ artifactId(庫本身的名稱) + version(版本)來定義坐標，通過xml來做配置文件，提供了中心倉庫(repo.maven.org)以及本地工具(mvn)。　　

依賴定義： 
 
　　<dependency>  
　　<groupId>com.google.guava</groupId>  
　　<artifactId>guava</artifactId>  
　　<version>18.0</version>  
　　</dependency> 
 
repo定義： 
 
　　<repository>  
　　<id>repo.default</id>  
　　<name>Internal Release Repository</name>  
　　<url>http://repo.xxxxxx.com/nexus/content/repositories/releases</url>  
　　<releases>  
　　<enabled>true</enabled>  
　　<updatePolicy>interval:60</updatePolicy>  
　　<checksumPolicy>warn</checksumPolicy>  
　　</releases>  
　　<snapshots>  
　　<enabled>false</enabled>  
　　<updatePolicy>always</updatePolicy>  
　　<checksumPolicy>warn</checksumPolicy>  
　　</snapshots>  
　　</repository> 

　　同時，為了避免依賴沖突的問題，Maven的依賴配置提供了exclude配置機制，用于阻斷部分庫的傳遞依賴。

　　Ruby的gem，Node的npm，Python的pip，iOS的CocoaPods都類似，只是配置文件語法和坐標命名規則有些差異。

　　至此，看起來Maven很簡單啊！為啥許多人會覺得Maven復雜呢?

　　主要在于以下兩點：

　　1.Java這樣需要編譯的語言，發布的庫是二進制版本的jar包，發布前需要有編譯的流程，而依賴和編譯是緊密相關的。不像Ruby，Node這樣的腳本語言，將源碼和配置文件扔到倉庫就可以。

　　2.Maven并沒有將自己單純的定義為依賴管理工具，而是項目管理工具，它將項目的整個生命周期都囊括進去了。

　　第二點也是Ant+ivy和Maven思路上的區別，ivy認為已經有Ant這樣的編譯打包工具了，只需在上面做個插件解決依賴問題即可，而Maven認為Ant本身也有改進的地方，所以一并改造了。

　　Maven的改進的核心思路是：Convention Over Configuration

　　即“約定大于配置”。既然大多數人習慣都把源碼目錄命名為src，那就約定好都用這個目錄，不用專門去配置。同樣，clean，compile，package等也約定好，不需要專門定義Ant task。這樣既簡化了配置文件，同時也降低了學習成本。一個Ant定義的項目，你需要閱讀幫助文件或者查看build.xml文件才能了解如何編譯打包，而Maven定義的項目直接運行“mvn package”即可。

　　Java語言發明的比較早，初期這種思想還不普及，所以Java本身沒有對項目的規范，而新的語言基本都吸收了這個思想，對項目都做了約定和規范。比如Go語言，如果用C/C++可能需要定義復雜的Makefile來定義編譯的規則，以及如何運行測試用例，而在Go中，這些都是約定好的。

　　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  
　　→ test → prepare-package → package  
　　→ pre-integration-test → integration-test  
　　→ post-integration-test → verify → install → deploy 

　　既然包含了這么多功能和階段，所以Maven引入了插件機制，Maven本身的編輯打包等功能都是用插件來實現的，也允許用戶自己定義插件。

　　同時涉及構建生命周期的不同的階段，依賴也需要確定是編譯依賴?測試依賴?運行時依賴?于是依賴多了scope的定義。

　　如果僅僅是這樣把Maven理解成標準化的Ant+ivy+可擴展的插件框架即可?但現實世界的項目往往更復雜。

　　我們有了function用于組合代碼塊邏輯，有了object用于組合一組方法，有了package，namespace用于組合一組相關對象，但其實還需要有更高一個層次的組合定義 —– module，或者叫子項目。同一個項目下，不同的源碼目錄可能需要編譯打包成不同的二進制文件，這些module共同構成了一個整體的項目。這個其實和源碼管理習慣有關系，是每個獨立的module作為單獨的源碼倉庫呢？還是將相關的module全部放在一起?從降低溝通成本的角度考慮，還是應該通過一個大的倉庫組織。

　　于是Maven引入了module的概念，同一個項目下可以有多個module，每個module有單獨的pom文件來定義，但為了避免重復，Maven的pom文件支持parent機制，子項目的pom文件繼承parent pom的基本配置。可以說，module的機制將Maven的復雜度又提升了一個層次，很多人遇到Maven的坑多栽到這里了。

　　這里介紹一個Maven多項目版本管理的***實踐：

　　1.父項目中配置版本號，子項目中不要顯示配置版本號，直接繼承父項目的版本號。

　　2.子項目之間的依賴通過${project.version}引用，不要明確配置版本號。

　　3.發布新版的時候，同時發布所有子項目，即便是該子項目未做變更。

　　4.***通過Maven的release插件發布，避免手動修改版本號導致的不一致問題。

　　即便是這樣，Maven的多項目版本管理經常也會遇到問題。主要是因為Maven的子項目之間的依賴也沿用的是第三方庫依賴的配置方式，需要指定子項目的版本號。另外子項目的parent需要顯式配置，也需要明確指定parent的版本號。一旦這些版本號出現錯誤，***就會導致各種詭異的問題。

　　Maven的release插件使用也比較復雜，該插件其實做幾個事情：

　　1.先構建一遍項目，確認項目可以正常構建。

　　2.修改pom文件的版本號到正式版，然后提交到源碼倉庫并打tag。

　　3.將該tag的源碼檢出，再構建一次，這次構建的jar包的版本是正式版的，將jar包上傳到Maven倉庫。

　　4.遞增版本號，修改pom文件的版本號到SNAPSHOT，再次提交到源碼倉庫。

　　這個過程中，由于要構建兩次，提交兩次源碼倉庫，上傳一次jar包，任何一步出錯都會導致release失敗，所以使用比較復雜。

　　到此，Maven的核心概念都分析完了，其他的都是插件機制上的一些擴展。大家也應該明白了Maven之所以***變這么復雜的原因。

　　但無論如何，Maven基本上是項目管理工具的標桿了，有的語言直接通過擴展插件來用Maven管理，比如C++，C#(NMaven)，或者做了移植Byldan(C#)，不過貌似都是不太成功，估計主要原因應該是Maven是用Java寫的，有社區隔膜。

　　Gradle對Maven的改進

　　聊了Maven的思路和優勢，那Maven的缺點呢?這個我們和Gradle一起聊聊。Gradle就是在Maven的基礎上進行的改進。優勢主要體現在以下方面：

　　1.配置語言

　　Maven使用的是XML，受限于XML的表達能力以及XML本身的冗余，會使pom.xml文件顯得冗長而笨重。而Gradle是基于Groovy定義的一種DSL語言，簡潔并且表達能力強大。在Maven中，任何擴展都需要通過Maven插件實現，但Gradle的配置文件本身就是一種語言，可以直接依賴任意Java庫，可以直接在build.gradle文件中像Ant一樣定義task，比Ant的表達能力更強(Ant本身也是XML定義的)。

　　Gradle的配置文件中可以直接獲取到Project對象以及環境變量，可以通過程序對build過程進行更細致的自定義控制，這個功能對于復雜的項目來說非常有用。

　　2.項目自包含(Self Provisioning Build Environment)

　　用戶下載了一個Maven定義的項目，如果沒用過Maven，還需要下載Maven工具包，了解Maven。但Gradle可以給項目生成一個 gradlew腳本，用戶直接運行gradlew腳本即可，該腳本會自動檢測本地是否已經有Gradle，沒有則從網絡下載，對用戶透明(當然，國內網絡下***還是自己先下載好)。

　　對倉庫的配置，Maven提供了一個本地的settings.xml配置文件，用于定義私有倉庫以及倉庫密碼這樣敏感的不應該放源碼倉庫里的文件。但這樣帶來的不便就是這些信息項目中沒有自包含，所以Gradle干掉了這種本地配置的機制，所有的定義都在項目里。私有倉庫密碼這樣的可以放在項目下的 gradle.properties文件里不提交上去，通過其他方式分享給內部成員。這點可能各有優劣。

　　3.任務依賴以及執行機制

　　Maven的構建生命周期的每一步都是預定義好的(參看前文)，插件任務只能在預留的生命周期中的某個階段切入，雖然Maven的生命周期階段考慮很充分，但有時候也不能滿足需求。Maven會嚴格按照生命周期的階段從開始線性執行任務，而Gradle則使用了Directed Acyclic Graph來檢測任務的依賴關系，決定哪些任務可以并行執行，這樣使任務的定義以及執行都更靈活。

　　4.依賴管理更為靈活

　　Maven對依賴管理比較嚴格，依賴必須是源碼倉庫的坐標。雖然也支持system scope的本地路徑配置，但還是有許多不方便之處(system scope的依賴，打包的時候不包含進來)。如果世界上所有的庫都通過Maven發布，當然沒有問題，但現實往往不是這樣的。這里要吐槽一下國內的各大廠發布的sdk之類的庫，幾乎都不提供倉庫地址，就給個壓縮包放一堆jar包進來，讓用戶自己搞定依賴管理問題。而Gradle在這方面比較靈活，比如支持：　　

compile fileTree(dir: 'libs', include: '*.jar') 

　　這樣的配置規則。

　　另外由于Gradle本身是一種語言，可以用編程的方式來管理依賴。比如大多數子項目都依賴某個庫，除了個別幾個，就可以這樣寫：

 

configure(subprojects.findAll {it.name != 'xxx1’ && it.name != ‘xxx2’}) {  
dependencies {  
compile("com.google.guava:guava:18.0”)  
}  
} 

　　5.子項目以及動態依賴機制

　　動態依賴主要是用來解決幾個互相依賴的庫都在快速開發期間的依賴問題，不能每次地層庫修改發布新版本，上層庫都要修改依賴配置文件，所以需要動態設置依賴***版本。

　　Maven的解決方案是SNAPSHOT機制，子項目之間也是通過這個機制來實現依賴的。遇到的問題我們前面也分析了。

　　Gradle的雖然也兼容Maven倉庫的SNAPSHOT機制，但它自己的版本管理機制上，并沒有引入SNAPSHOT機制。它的依賴支持4.x，2.+這樣的配置規則，實現動態依賴(注：Maven也支持類似的規則，參看 Dependency Version Requirement Specification)。而子項目之間的依賴采用特殊的依賴配置，和第三方庫的配置規則有區別。它直接使用：　　

compile project(“:subpoject-name”); 

　　這樣的配置，無需配置版本號，明確指定是子項目，避免Maven的子項目依賴帶來的版本號問題。子項目的配置中也不需要顯示配置父項目，只需要父項目單向中配置子項目列表即可。

　　同時Gradle的release機制也更為靈活，支持release到各種倉庫(包括Maven倉庫)，但不控制release過程中的版本號生成，修改源碼倉庫等步驟，留給用戶自己通過手動或者CI工具，或者腳本去解決。

　　關于Gradle相對Maven的改進這里主要列舉這幾點，其他的可以參看Gradle官方的比較表格：maven_vs_gradle，這里不再詳述。

　　Go語言的多項目以及依賴管理問題

　　***再談談Go語言的多項目以及依賴管理問題。Go官方對這兩方面并未做約定或者提供工具，于是只能各自想辦法解決。多項目問題一般就是回歸到了 Makefile+腳本的解決方案，比如kubernetes。依賴管理，開源社區多用Godeps，kubernetes用的也是這個。Godeps通過源碼倉庫路徑以及源碼tag來確定庫的坐標，只管理依賴，有點像ivy，不關心構建過程。Godepes會將依賴庫的依賴也添加到當前項目的依賴配置中，不是動態的依賴傳遞機制。沒有scope，不區分是否是單元測試的依賴。一個倉庫只支持一個配置，沒有子項目概念，項目大了管理就比較復雜。另外它對傳遞依賴以及版本沖突的問題當前還是沒有解決太好(有一些相關Issue)。

　　一個語言的多項目以及依賴管理方案對這個語言的生態發展有很大的影響，Java發展到現在，Maven以及Gradle功不可沒，所以感覺Go官方應該對這兩方面有所作為。Go語言遲遲沒出依賴管理工具，個人覺得有幾方面考慮：

　　1.Go尚未確定動態庫的機制。編譯型語言依賴***也是二進制的，而不是源碼。一方面可以加快編譯速度，另外一方面也可以實現源碼保護，方便分發以及代理緩存，讓語言的適用范圍更廣。許多商業上的庫是不方便提供源碼的。所以依賴管理工具的實現需要動態庫的機制。而動態庫尚未確定的原因我覺得是Go 語言不想過早的引入二進制動態庫的格式兼容問題，初期全部用源碼是最省事的。

　　2.先讓社區試試水，看看效果和反饋。

　　任何一個語言，發展到一定階段都避不開依賴管理問題。前一段時間看到一篇寫Go語言的文章，嘲諷Java的Maven構建個項目恨不能把半個互聯網下載下來，我當時腦海中就浮現出長者的那句經典語錄“圖樣圖森破”。Go當前沒遇到這些問題的原因只是Go還比較年輕，庫還不夠豐富，以及Go的很多項目還不夠復雜。而像kubernetes這樣的項目，當前依賴已經有226個了，構建一下，也快要下載半個Github了。所以個人覺得Go社區當前還是非常需要一個類似于Gradle的工具，來解決依賴管理，構建，多項目管理等問題。