英文原文：
http://ant.apache.org/ivy/history/2.1.0-rc1/concept.html
因內容太長而拆分，下面是第一部分：
一. 依賴解析器
依賴解析器是ivy中使用的可插入是的類：
* 發現ivy文件中的依賴
* 下載依賴的制品
制品下載的概念很大：制品可以在網站上，或者在你機器上的本地文件系統上。下載是從倉庫取文件放到ivy緩存的行為。
而且，解析器的職責是找到ivy文件并下載制品，這有助于實現不同的解析策略。
如你所見，依賴解析器可以被認為是負責描述倉庫的類。
如果你想知道在ivy中有哪些解析器可用，你可以轉到對應的配置章節。
二. 模塊配置說明
模塊配置在術語頁面已經被描述，是用來使用或者構建模塊的方法。配置是ivy的重要部分，需要更多的說明。
當你定義一種方式來使用或者構建模塊時，你可以在這個配置中定義哪些制品被這個模塊發布，并且你還可以在這個配置中定義哪些依賴是需要的。
此外，因為ivy中的依賴是以模塊而不是制品來表述，因此能夠在你定義的模塊中定義依賴的配置是必須的就顯得很重要了。這就是配置映射。
如果你僅僅使用單一的模塊并且不想操心配置，你可以不理會他們。它們依然存在，導致ivy無法在沒有配置的情況下工作。但是大多數時候，如果你不定義任何東西，ivy會假設你的模塊的制品在所有的配置中發行，并且在所有的配置中所有的依賴配置都是必須的。并且在單一模塊的情況下工作正常。但是無論何時你想在一個模塊內部分隔事物，或者更多的控制發行的東西并通過依賴解析，配置會滿足你的大多數要求。
更多如何定義模塊配置，定義制品用哪個配置發布和定義配置映射的細節，請參考ivy文檔。配置教程是一個可以教會你學到更多關于這個概念的東西的好地方。
三. 變量
在配置的過程中，ivy容許定義ivy變量。ivy變量可以被視為類似ant屬性，而且使用方式很相似。特別是，在配置文件中使用屬性標簽來裝載包含ivy變量和值的屬性文件。
但是，ant屬性和ivy變量之間的最大差別在于ivy變量可以被覆蓋，然而ant屬性不可以，而且它們在不同的環境下定義。
實際上當配置完成時，所有ant屬性都被導入到ivy變量（如果是從ant中調用ivy）。這意味著如果你在調用配置之后定義一個ant屬性，它講無法作為一個ivy變量來訪問。另一方面，ivy變量不能導出到ant，所有如果你在ivy中定義ivy變量，不要試圖作為ant屬性來使用它們。
為了使用ivy變量，你必須遵循和ant屬性相同的語法：
${variablename}
這個的variablename是變量名
最后，同樣重要的是知道變量代入的時間點。帶入是盡可能快的。這意味著當ivy遇到一個變量引用，如果這個變量被定義了，它會試圖代入。結果是，這個變量在之后的任何改動都不會影響這個已經代入的值。
此外，在ant環境中，一串變量將通過ant屬性文件裝載機制被默認設值（實際上他們被作為ant屬性第一次裝載，然后被導入為ivy變量，見ant任務），甚至在ant屬性自身也將在裝載時立即代入，有效地使得僅僅通過ivysettings.properties文件來覆蓋某些變量變得沒有可能。某些變量因此只能通過ant屬性來重載。
此外，同樣非常重要的是理解ivy變量和ivy模式標記(pattern tokens)之間的不同。請翻閱模式的章節來理解什么是模式標記。
四. 模式
ivy模式在很多依賴解析器和ivy任務中被使用，是構成ivy工作方式的簡單方法。
首先我們給出一個例子。距離說你可以通過提供一個查找制品的模式來配置一個文件系統依賴解析器。這個模式類似這樣：
myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
這個模式表明我們使用的倉庫是在被稱為myrepository的目錄中。
在這個目錄中有我們要查找的名為組織和模塊的目錄。那么每個模塊一個目錄，名字就是模塊名。然后在每個模塊目錄中我們發現每個制品類型(jars, wars, ivys, ...)有一個目錄，在這些目錄中我們發現制品被命名為制品id，加一個連字符（橫杠），然后是修訂本，逗號，制品的擴展名。
不是很難理解吧？就是這樣，現在你能理解模式的概念了！
多解釋一點，模式是由標記組成的，當賦值給特定的制品或模塊時標記被替換為實際的值。這些標記和變量不同，因為它們為每個制品做不同的替換，然而變量通常是相同的值。
你可以在模式中混合使用變量和標記：
${repository.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
標記是否有用取決于模式在哪里被使用（例如賦值給制品或者模塊），但是這里是所有目前可用的標記：
* [organisation] 組織名
* [module] 模塊名
* [branch] 分支名
* [revision] 修訂本
* [artifact] 制品名(或者id)
* [type] 制品類型
* [ext] 制品文件擴展名
* [conf] 配置名
* [originalname] (since 1.4) 原始的制品名（包括擴展名）
類型和擴展名的不同在ivy文件文檔中已經解釋過了。
從1.2開始， [organization] 可以被 [organisation] 替代使用.
從1.3開始， 在模式中可以使用可選部分。
這使得當標志沒有定義時可是避免某些輸入，而不是僅僅得到一個空的標記。括號被用于界定可選部分，并且在括號中只能有一個標記。因此如果在你在用'(' 和 ')'包圍一個標記，如果標記沒有值則在括號之間的任何其他文本都將被忽略。
例如, 假設有這樣一個模式: "abc(def[type]ghi)"
type = "jar" -> 模式展開為: abcdefjarghi
type = null 或者 "" -> 模式展開為: abc
更實際的例子：模式[artifact](-[revision]).[ext]
讓你同時接受在修訂本被設置時的myartifact-1.0.jar和沒有設置修訂本時的myartifact.jar(而不是myartifact-.jar)。在你需要保持對制品名的控制時非常有用。
從1.4開始，附加屬性可以在模式中被當成任意其他標記被使用。
五. 最新策略
ivy經常需要知道兩個修訂本之間哪個是最新。為了知道這個，ivy使用"最新策略"的概念。當然，有多個方法可以考慮一個修訂本是否是最新。你可以選擇一個已經存在的或者插入你自己的。
但是在知道那個修訂本是最新的之前，ivy需要有能力去考慮一個模塊的多個修訂本。因此ivy不得不從目錄下得到一個文件列表，為此需要使用依賴解析器。因此在奇怪為什么ivy沒有得到你最新的修訂本前，請檢查你使用的依賴解析器是否和最新的修訂本兼容。
最后，為了得到模塊的不同修訂本，大多數時候你需要在你的模式中使用[revision]標記，這樣無論revision是什么ivy都能得到匹配這個模式所有的文件。只有這樣來時使用最新策略來檢測那個修訂本是最新的。
ivy有三個內建的最新策略：
* latest-time
比較修訂本時間來知道哪個是最新的。雖然相對來說這通常是一個好的策略，但是它有一個缺點，和遠程倉庫進行推斷是有代價的。例如如果你使用ivyrep，ivy不得不在知道哪個是最新的之前詢問http服務器每個ivy文件的日期。
* latest-revision
把修訂本進行字符串比較，使用接近于php version_compare 函數的算法。這個算法被用于評估某些文本的特殊含義。例如，這這個策略中，1.0-dev1 被認為在1.0-alpha1之前, 1.0-alpha1在1.0-rc1之前, 1.0-rc1在1.0之前, 1.0在1.0.1之前.
* latest-lexico
把修訂本進行字符串比較，使用辭典順序(這個方法被java strong 比較使用)
六. 沖突管理器
沖突管理器可以在沖突的模塊修訂本列表中選擇需要保留的修訂本。
如果修訂本對應相同的模塊，舉例說相同的組織/模塊名對，那么稱為沖突的修訂本列表。
可用的沖突管理器列表在可以沖突管理器頁面可以得到。
想得到更多如果配置沖突管理器的細節，請看ivy文件參考的沖突章節。