Ivy 的主要概念

依賴解析器（Dependency Resolver）

        依賴解析器是ivy裏一個可插拔的類，主要用來找到依賴組件的ivy file，下載依賴的組件。「下載」的概念比較普遍：組件能夠在web服務器或者本地文件系統。這時候的下載其實就是將文件從庫裏轉存到ivy緩存中。此外，resolver的責任還有找到ivy文件而且下載組件，幫助實現不一樣的解析策略。正如你所見，依賴解析器能夠理解爲用來描述庫的類。

模塊配置說明（Module configurations explained ）

      配置是Ivy的重要部分，當你定義一個使用或者構建模塊的方法時，你能夠定義在某個配置裏的模塊要發佈哪些組件，你也能夠定義這個配置裏都須要哪些依賴關係。

       此外，ivy的依賴關係是在模塊上來表述而不是在組件上，重要的是可以定義哪些依賴的配置在你定義的模塊配置裏是須要的（it is important to be able to define which configurations of the dependency are required in the configuration you define of your module.）這就是所謂的配置映射（configuration mapping）

       若是你用的只是簡單的模塊，不想考慮配置問題，你不須要擔憂。它們依然存在，由於ivy的工做離不開配置。更多的時候你什麼都不用聲明，ivy認爲在全部配置裏你模塊的組件都要發佈，一樣在全部配置裏任何依賴配置都是須要的。可是當你想要把模塊裏的東西拆分或者更多的控制文件的發佈以及更好的依賴解決方案，配置會知足你大多數需求

變量（Variables）

    Ivy變量能夠慚怍ant的屬性，用法也相似。特別是，你能夠在配置文件裏用屬性標籤來加載包括ivy變量和值的屬性文件。

     ant屬性和ivy變量的主要區別是ivy變量能夠被覆寫（可是ant 屬性不能夠），而且它們是定義在不一樣的環境裏。

     若是你從ant調用ivy，全部的ant屬性都會在配置結束的時候導入到ivy變量裏。這意味着若是你在嗲用配置以後定義了一個ant屬性，這個屬性是不不能當作ivy變量來用的。另外一方面，ivy變量是不會輸出到ant裏，所以當你在ivy裏定義了ivy變量，就不要再嘗試將它們用做ant屬性。

     要使用ivy變量，你只須要遵循和ant屬性同樣的語法就能夠了：${變量名}

     最後，知道變量替換的時間也很重要。變量替換會盡快完成，這意味着當ivy遇到一個引用變量，它會嘗試去替換，前提是這個變量已經定義好了。所以，稍後的任何改變都不會更改已經替換了的值。

     此外，在ant環境裏，一堆變量會默認經過ant屬性文件加載機制設置（事實上他們首先被做爲ant屬性加載，而後做爲ivy變量導入，參考 Ant Tasks），甚至在ant變量裏它們也會在加載的時候替換，有效的阻止了一些變量經過ivysetings.properties被徹底覆寫。 某些變量只能經過ant屬性來覆寫就是由於這個。

   另外，理解ivy變量和ivy 模式標記（pattern tokens）也很是重要

模式（Patterns）

      Ivy 模式用於不少依賴解析器和ivy task中，是ivy工做的一種簡單方法。

      舉個例子，你能夠給文件系統的依賴解析器配置一種模式來找到相關的組件，這個模式能夠像這樣寫：

myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext] 這個模式代表，咱們使用的存儲庫是一個名叫myrepository的目錄。在這個目錄中，咱們有以咱們須要尋找的模塊的組織名命名的目錄，接着是每一個模塊的目錄，每一個目錄都是以模塊名命名的。而後在模塊目錄裏咱們能夠找到每一個組件類型（jars,wars,ivy...）的目錄，在這些目錄裏咱們能夠找到以id命名的組件，後面是連字符，修訂版本，點號以及組件的擴展名。並不難理解。

      再多點解釋，一種模式是由一組標記組成，當匹配特定的組件或模塊時這些標記會被實際的值取代。這些標記和變量不一樣由於它會被不一樣的組件以不一樣的值取代，而變量一般是相同的值。

      你能夠將變量和標記混合起來用在模式中：

${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]這些標記是否可用取決於模式再哪裏用（例如，它會被組件或者模塊來評估嗎）. 當前全部可用的標記以下：

• [organisation] 組織名

• [orgPath] (since 2.3) "."被替換爲"/"的組織名。可用來配置相似maven2的存儲庫

• [module] 模塊名

• [branch] 分支名

• [revision] 修訂版

• [artifact] 組件名或id

• [type] 組件類型

• [ext] 組件的擴展名

• [conf] 配置文件名

• [originalname] (since 1.4) 原始組件名（包括後綴）

 since 1.3， 模式中能夠有可選的部分。若是某個標記沒有定義就不會有輸入，也避免了只有一個空的標記留在那裏。圓括號用來界定可選部分，而且括號中只能有一個標記。也就是說，若是你用"("和")"將一個標記括起來，若是標記沒有定義，那麼這個括號內的其餘字符也會被忽略。例如， 假設一個模式是"abc(def[type]ghi)", 若是type="jar" 那麼替換後的模式是abcdefjarghi，若是type=null 或者""， 替換後的模式就是abc。

   更實際的例子如: [artifact](-[revision]).[ext],能夠陪陪到myartifact-1.0.jar 和 myartifact.jar。這個在你須要控制組件名字的時候尤爲有用

 since 1.4 擴展屬性能夠在模式裏用做其餘標記

最新策略（Latest Strategy）   

       Ivy常常須要知道兩個版本中哪個是比較新的，它使用最新策略概念來達到此目的。事實上，有不少種方法能夠界定最新版本。捏能夠選擇已存在或者插入你本身的。

      在知道哪個版本比較新以前，ivy須要可以比較一個模塊的幾個修訂版。這樣ivy就須要拿到一個目錄下的文件一個列表,它使用依賴解析器來實現。在考慮爲何ivy不能獲得你的最新修訂版以前，先檢查你用的依賴解析器是否可最新修訂版匹配。

    最後，爲了獲得一個模塊的多個修訂版，大多數時候你須要在你的模式中用[revision]標記，使ivy得到全部和該模式匹配的文件，無論它的修訂版是多少。而後最新策略才能肯定哪一個版本是最新的。

  Ivy 有三個內置的最新策略：

• latest-time

  比較修訂版日期來肯定哪個是最新的。就針對性而言這一般是比較好的策略，但其缺點是在計算距離較遠的存儲庫的時候會很耗成本。例如當你用ivyrep時，ivy必須問http服務器每一個ivy文件的日期才能知道哪個是最新的。

• latest-revision

  將修訂版當字符串來比較，使用和php 版本比較功能相接近的算法。該算法考慮一些文本的特殊含義。例如，這個策略中按時間順序1.0-dev1->1.0-alpha1->1.0-rc1->1.0->1.0.1.

• latest-lexico

  將修訂版當字符串來比較 ,按字母順序（java字符串比較所使用的順序）

衝突管理器（conflict Manager）  

       衝突管理器能夠在有衝突的模塊版本中選擇保存一個或多個版本。若是一系列修訂版對應於同一個模塊，例如相同的組織或者模塊名，就說它們有衝突。

        可用的衝突管理器列表見衝突管理器配置

模式匹配器（Pattern matcher）

      在不少地方ivy使用模式去匹配一組對象。例如你在使用模式匹配聲明依賴關係時能夠一次排除多個模塊。Ivy使用可插拔的模式匹配器去陪陪這些對象名。有3個是默認定義好的：

• exact： 只使用按字符匹配

• regexp :since 1.4，可使用java模式類支持的正則表達式

• glob： 可使用相似Unix的全局匹配器，例如 元字符「*」匹配任意字符，？配置一個字符。注意，該匹配器只有在jakarta oro 2.0.0在你的classpath中時纔可用

擴展屬性(Extra attributes) 

     since 1.4 ivy xml文件裏的不少標籤都是可被擴展屬性擴展的。概念很是簡單：若是你須要更多的信息來定義你的模塊，你能夠添加你想要的屬性，而且你能夠像其餘屬性同樣在你的模式中訪問它。

     since 2.0 你能夠而且也建議你在擴展屬性中使用xml 命名空間。使用Ivy擴展命名空間是添加你本身擴展屬性最簡單的方法。這裏有一個ivy文件，裏面的「color」屬性設置爲blue:   

<ivy-module version="2.0" xmlns:e="http://ant.apache.org/ivy/extra">
	<info organisation="apache"
	       module="foo"
	       e:color="blue"
	       status="integration"
	       revision="1.59"
	/>
</ivy-module>

     這樣一來，當你聲明foo的依賴時你必須使用這些擴展屬性。這些擴展屬性會被用來當作模塊的標識符，相似org名字和修訂版本。

<dependency org="apache" name="foo" e:color="blue" rev="1.5+" />

       你也能夠像這樣定義你的存儲庫模式：

${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]

     注意，在模式中你必須使用未經修飾的屬性名（沒有命名空間作前綴）

     若是你不想使用xml命名空間，這個是能夠的，可是你須要禁止ivy文件校驗，由於你的文件再也不符合官方ivy定義。

校驗碼（Checksums） 

    since 1.4 Ivy容許使用校驗碼，也稱爲摘要（digests），來驗證下載文件的的正確性。

    目前Ivy支持md5和sha1算法。使用md5和sha1的配置須要全局或者依賴解析器完成。全局地，使用ivy.checksums變量列出須要完成的校驗（只支持md5和sha1）。在每一個解析器裏，你可使用校驗碼屬性覆寫全局設置。

    設置是一個用逗號分開的校驗碼算法列表 。在校驗期間（下載的時候），使用第一個找到的校驗碼去作校驗，就這樣。這意味着，若是你用了「sha1,md5」設置，會比較下載文件的sha1和設置的sha1，若是比較結果正確，那個這個文件就會被認爲是正確的。若是沒有找到sha1文件，會繼續找md5文件，若是都沒有找到，就不作校驗。

    在發佈期間，全部列出來的校驗碼算法都會被計算而且上傳。

    校驗碼算法默認是 "sha1，md5"。若是你想更改這個默認設置，你能夠設置變量ivy.checksums。所以，要想禁止校驗碼校驗你只須要將ivy.checksums設置爲「」就能夠了。

事件和觸發器（Events and Triggers）

   since 1.4 當Ivy執行依賴解析和其餘任務時，它會在最重要的步驟以前和以後觸發事件。你可使用Ivy API來監聽這些事件，或者你甚至能夠註冊一個觸發器在特定事件發生的時候去執行一個特定的行爲，這是一個很是強大且靈活的功能，它使你能夠在一個依賴被解析以前執行構建，或者精確的追蹤在依賴解析的過程當中到底發生了什麼，等等。

循環依賴（Circular Dependencies）

   since 1.4 循環依賴能夠是直接的或間接地。例如，A 依賴A，這個循環依賴，A依賴B，B又依賴A，這也是循環依賴。

在1.4以前，循環依賴會引發Ivy錯誤。自從1.4以後，Ivy能夠經過循環依賴策略找到循環依賴是可配置的。可用的三個內置策略：

• ignore：循環依賴只表示爲冗餘信息（circular dependencies are only signaled in verbose messages）

• warn：除了會表示爲警告外，和ignore同樣.

• error：當發現循環依賴時中止依賴解析

緩存和變動管理（Cache and Change Management）

      Ivy很是依賴於本地緩存，一次來避免常常性的訪問遠程庫，也節省了不少網絡帶寬和時間。

      緩存類型：

       Ivy緩存由兩個不一樣的部分組成：   

• 存儲庫緩存（the repository cache）：是Ivy存儲從模塊庫裏下載來的數據的地方，以及一些關於這些組件的原數據信息，例如原始的位置。這部分緩存是能夠共享的，可是你的有一個很是合適的鎖策略（lock strategy）

• 解析緩存（the resolution cache）：這部分緩存用來存儲解析數據，Ivy用來重複使用解析過程的結果。這部分緩存會在每次新的解析執行以後被覆寫，不該該被多進程同時使用。

  雖然始終只有一個解析緩存，你能夠定義多個存儲庫緩存，每一個解析器可使用單獨的緩存。

        變動管理

        爲了優化依賴解析和緩存的使用方式，Ivy默認假定修訂版不會改變。所以一旦Ivy模塊（元數據和組件）在緩存中，它就信任緩存而且不會再去查詢存儲庫。這個優化在不少狀況下很是有用，而且不會引發問題，前提是你遵循這個慣例：修訂版永遠不會變。除了性能，還有其餘很是好的理由去遵照這個原則。然而，根據你當前的構建系統和依賴管理策略，你可能更喜歡時不時更新你的模塊。有兩種改變須要考慮：

       原數據變動：

        由於模塊的提供者並不會像關注API或者行爲那樣常常考慮模塊原數據（即便他提供了模塊原數據），這個常常發生，咱們被不得不更新模塊原數據：某個依賴被忘記，或者另一個丟失，... 在這種狀況下能夠在依賴管理器裏設置 checkModified="true"來解決。這個標識告訴Ivy去檢查與緩存中的數據相比模塊元數據是否被修改。Ivy首先在須要的時候檢查要下載存的儲庫中元數據的最後修改的時間戳，而後在須要的時候進行更新。

        組件變動

        有些人，尤爲是時從maven 2 轉過來的，喜歡使用一個特殊的修訂版來處理常常更新的模塊。在maven 2中被稱爲SNAPSHOT版本，有爭論說這樣能夠幫助節省磁盤空間，在開發期間生成大量中間構建物中只保存一個版本。

        Ivy用「變動修正版」（changing revision）概念來支持這種方法。一個變動修正版就是：Ivy認爲通過一段時間組件會改變的一個修訂版。爲了處理這個，你能夠指定一個依賴做爲依賴標識變動（？you can either specify a dependency as changing on the dependency tag），或者在解析器中使用變動模式（changingPattern）和變動匹配器（changingMatcher）屬性來講明哪一個修訂版或者那組修訂版應該被認爲會改變。

        一旦Ivy知道了某個版本會改變，它會遵照這個原則來避免過多的檢查你的存儲庫：若是模塊的原數據沒有變，那麼整個模塊（包括組件）都麼有變。儘管模塊的描述文件改變了，它也會檢查模塊的發佈數據去看看是不是新發布的相同修訂版。這時若是發佈日期改變了，它會去檢查組件的最後修改時間，而後作相應的下載。

      所以若是你想使用變動修訂版，使用publish任務區發佈你的模塊，它會注意更新發布日期，全部的事情都會順利進行。還有記得在你的解析器裏設置checkModified="true"！

路徑處理（Paths handling）
     做爲一個依賴管理工具，Ivy有不少文件相關的操做，大多數時候會使用到路徑或者路徑模式來定位文件系統中的文件。這些路徑能夠是相對或絕對路徑。咱們建議一直使用絕對路徑，這樣你就不用但系相對路徑的基礎是什麼。Ivy提供了一些變量，能夠用來做爲你絕對路徑的基礎。例如，Ivy有基礎目錄的概念，基本上和Ant同樣。你能夠用ivy.basedir變量來訪問這個基礎目錄。所以若是你的路徑時這樣的：${ivy.basedir}/ivy.xml, 你就有一個絕對路徑，在設置文件裏，也有一個稱爲ivy.settings.dir的變量指向設置件的目錄位置，是的定義到這個文件的相對路徑很是容易。

     若是你真的想使用相對路徑，實際用來定位文件的基礎路徑依賴於相對路徑在哪裏定義：

• 在Ivy文件裏，路徑相對於文件Ivy文件自己（在Ivy文件裏惟一可能的路徑就是包含配置聲明）

• 在設置文件中，包含文件的路徑（也就是屬性文件的加載和內容設置）是相對於設置文件的目錄位置。其餘全部的路徑必須是絕對的除非有明確說明

• 在Ivy的Ant任務和Ivy參數或選項中，路徑是相對於Ivy的基礎目錄，當從Ant調用時，就是你的Ant basedir