在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 / 仓库

一. 概述

    下面的插图展示了所有的关键术语：

   

二. 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来做这些。