在ivy中使用了很多術語，他們的定義如下：
* Organisation / 組織
* Module / 模塊
* Module Descriptor / 模塊描述符
* Artifact / 制品
* Type of an artifact / 制品類型
* Artifact file name extension / 制品文件擴展名
* Module Revision / 模塊修訂本
* Branch / 分支
* Status of a revision / 修訂本狀態
* Configurations of a module / 模塊配置
* Ivy Settings / ivy設置
* Repository / 倉庫
一. 概述
下面的插圖展示了所有的關鍵術語：
http://ant.apache.org/ivy/history/2.1.0-rc1/images/ivy-terminology.png
二. Organisation / 組織
組織可以是公司，個人，或者僅僅是任何開發軟件的一組人。原則上，ivy僅處理單一級別的組織，這意味著他們在ivy模塊描述符中擁有一個扁平的命名空間。因此，如果使用分層的命名習慣，用ivy的描述符只能描述樹形組織結構。組織名用來將同一個團隊生產的軟件保持一致，僅僅是幫助定位他們發布的。
作品。
在ivy中通常使用反轉的域名作為組織名，因為域名是獨一無二的。域名為www.example.com的公司可以使用com.example，或者如果他們有多個團隊，他們的組織名可以以com.example開頭(例如com.example.rd, com.example.infra, com.example.services)。組織名并不強制要求一定要是域名反轉，或者全局唯一，但是唯一的名字是高度推薦的。被廣泛認可的商標或者商業名的擁有者可以選擇使用他們商標名。如org.apache, ibm, jayasoft
注意ivy的“組織”非常類似maven POM 中的"groupId"。
三. Module / 模塊
模塊是一個完備的可重用的軟件單元，帶有一個修訂版控制方案。
ivy僅關心模塊的發布比如大家熟知的"artifacts"，還有用于表示他們的模塊描述符。這些發布，包括模塊的每一個修訂版本，在倉庫中管理。換句話說，對于ivy，一個模塊就像一個修訂版本鏈，每個修訂版本由一個描述符和一個或多個artifact構成。例如：hibernate-entitymanager, ant
模塊描述符
模塊描述符是識別模塊的一般方法：識別符(組織，模塊名，分支和修訂版本)，已發布的制品，可能的配置和依賴。
在ivy中最通用的模塊描述符是Ivy Files，帶有ivy特定語法的xml文件，通常被稱為ivy.xml。
但是既然ivy同樣兼容maven2的原數據格式(名為pom, Project Object Model, 項目對象模型), pom文件也可以作為模塊描述符使用。
而且由于ivy支持可插入式的模塊描述符解析器，因此幾乎可以使用任何東西作為模塊描述符。
四. Artifact / 制品
制品是一個為模塊修訂版本的發布而準備的單獨文件，作為開發的一個產品。
通常推薦使用壓縮包格式，因為容易管理，傳送和存儲。同樣的理由，通常一個模塊只有一個或者很少的制品。無論如何，制品可以是任意文件類型，在一個單獨的模塊中可以申明任意數量。
在java的世界種，通常的制品是Java archives 或者說jar文件。在很多情況下，模塊的每個修訂版本只發布一個制品(例如 jakarta-log4j-1.2.6.tar.gz), 但是他們中的一些發布多個制品，取決于模塊的使用。(像 apache-ant 二進制和源文件，分別打包為zip, gz 和bz2 格式).例如: ant-1.7.0-bin.zip, apache-ant-1.7.0-src.tar.gz
制品類型
制品類型是一個特別類型的制品范例的范疇（翻譯的很暈，原文：The artifact type is a category of a particular kind of artifact specimen.）。 這是基于制品的已制定計劃或者制品如何提供的分類法，而不是包的格式類型或者制品如何發布。
雖然制品的類型可能暗示它的文件格式，但是他們是兩個不同的概念。制品的文件擴展名和它的格式聯系更緊密。例如，Java archives的情況，制品類型"jar"顯示它確實是一個Java archive文件，符合JAR文件規范。它的文件擴展名只是湊巧也是"jar"。另一方面，對于源文件發布包，制品類型可能是"source"，雖然文件擴展名可以是"tar.gz", "zip", "java", "c", 或 "xml"。所以，制品類型基本上是用來解釋它的目的的抽象功能類別，而制品文件擴展名是更加具體的技術上的文件格式和名稱的標記。
定義模塊的適當的制品類型由開發組織決定。通常的選擇包括: "jar", "binary", "bin", "rc", "exe", "dll", "source", "src", "config", "conf", "cfg", "doc", "api", "spec", "manual", "man", "data", "var", "resource", "res", "sql", "schema", "deploy", "install", "setup", "distrib", "distro", "distr", "dist", "bundle", 等等.
模塊描述符不是真正的制品，但是他們可以作為一個制品類型，比如"descriptor"(ivy file 或者 Maven POM).
電子簽名或者摘要本身不是真正的制品，但是他們可以再倉庫中被找到。他們也被作為一種制品類型，例如"digest" (md5 or sha1)。
五. 模塊修訂本和狀態
模塊修訂本
模塊的每一個被發布的唯一狀態都被分配一個唯一的修訂本編號或者版本名。ivy可以幫助為模塊的發布生成修訂本編號，并將修訂本發行到倉庫中，但是修訂本控制的其他方便，尤其是源文件修訂，必須由單獨的版本控制系統管理。
因此，對于ivy，修訂本經常對應模塊的一個發布版本。它可以是public, shared 或 local delivery，一個發布，一個里程碑或者一個集成構造，一個alpha或者bata版本，一個nightly build, 或者甚至是一個持續構造。它們都被ivy視為修訂本。
在某些情況下，源文件控制系統的源文件修訂本編號可以被用來作為模塊的修訂本編號，但是這種用法非常少見。它們是兩個不同的概念，即使模塊的修訂本編號是完全或部分從源文件修訂本編號中復制過來。
分支
分支對應于源文件控制管理工具中的分支(有時是stream/流)的標準含義。head, 或者trunk, 或者main stream都被ivy視為分支。
修訂本狀態
模塊的狀態顯示模塊的修訂本的穩定程度。它被用來統一所有模塊依賴的狀態，防止在模塊的release中使用依賴的集成修訂本。
ivy默認定義三種狀態
* integration/集成: continuous build，nightly build等產生的修訂本歸于此類
* milestone/里程碑: 發布給公眾但是還沒有真正完成的修訂本歸于此類
* release/發行: 完整測試并被打好標簽的修訂本歸于此類
在1.4版本之后，這個列表可以在settings file/設置文件中配置。
六. 模塊配置
模塊配置是使用或者構建一個模塊的方法。如果同一個模塊有不同的依賴，基于如何使用，在ivy中這些不同的依賴組合被稱為它的配置。
一些模塊可能以不同的方式被使用(考慮hibernate，可以在應用服務器內部或者外部使用)，而這種方式可能改變你需要的制品(這種情況下的hibernate, jta.jar僅僅當它被在應用服務器外部使用時才需要)。此外，模塊可能僅僅在build時需要一些其他模塊或者制品，而在運行時需要其他一些。所有這些不同的使用或者構建模塊方式在ivy中被稱為模塊配置。
更多配置和他們在ivy中如何被使用的細節，請參考主要概念的頁面。
七. ivy設置
ivy設置文件是xml文件，用于配置ivy來指示從哪里可以找到模塊和如何找到模塊。
設置的歷史
在ivy2.0之前，設置文件被稱為配置文件，通常名為為ivyconf.xml。這導致了模塊配置和ivy配置文件之間的混淆，因此被重命名為配置文件。如果你偶爾發現ivyconf文件，或者某些被稱為配置文件的東西，大多數情況下都只是因為它是沒有更新的信息(文檔，指南和文章). 可以隨便報告任何類似這樣的問題，如果你在這封文檔中發現這樣的不一致。
八. 倉庫
在ivy中，被稱為倉庫的是ivy用來發現你要求的模塊的制品和描述符的分布站點位置(也就是大多數情況下的ivy文件)。ivy可以使用非常精巧的配置的復雜倉庫。你可以使用Dependency Resolvers來做這些。