六. 冲突管理器

    冲突管理器可以在冲突的模块修订本列表中选择需要保留的修订本。

    如果修订本对应相同的模块，举例说相同的组织/模块名对，那么称为冲突的修订本列表。

    可用的冲突管理器列表在可以冲突管理器页面可以得到。

    想得到更多如果配置冲突管理器的细节，请看ivy文件参考的冲突章节。

七. Pattern matcher 模式匹配

    从1.3之后在很多地方ivy使用模式来匹配一系列对象。例如，当通过使用匹配所有想排除的模块的模式来声明一个依赖时，你可以立即排除这多个模块。

    ivy使用可插入式的模式匹配器来匹配哪些对象名。默认定义好的有3个：

    * exact
        This matcher matches only string when they are equal to the pattern one
        这个匹配器仅匹配字符串，要求和模式相同。

    * regexp
    这个匹配器容许你使用java1.4或者更高版本的Pattern类支持的正则表达式

    * glob
    这个匹配器容许你使用unix风格的glob匹配器，仅有的能使用的字符是匹配任何字符串的*和精确匹配单个字符的?。注意仅仅当jakarta oro2.0.8在classpath中时这个匹配器才可以使用。

    同样请注意，在任何匹配器中，字符'*'有匹配任意东西的特殊含义。对于不依赖匹配器的默认值尤其有用。


八. 附加属性

    从1.4版本之后在ivy的xml文件中有几个标签是可以通过被称为附加属性的东西来进行扩展。想法很简单：如果你需要更多信息来定义你的模块，你可以添加你需要的属性，然后能够像访问其他属性一样访问它，比如在你的模式中。
    从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，name和revision。
    <dependency org="apache" name="foo" e:color="blue" rev="1.5+" />
    你还可以这样定义你的仓库模式:
    ${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
    注意在模式中科你必须使用非限定属性名(不带命名空间前缀)

    如果你不想使用xml命名空间，这是可以做到的，但是你需要使ivy文件验证失效，因为你的文件不再符合任何正式的ivy xsd。查看设置文档来得知如何使验证失效。


九. 校验和
    从1.4版本后，ivy容许使用校验和，被称为digester，来验证下载文件的正确性。
    目前ivy支持MD5和sha1算法。

    使用MD5还是sha1的配置可以是全局的，或者是由依赖解析器设置。全局是使用变量ivy.checksums来列举要进行的检测(仅支持md5和sha1)，在每个解析器上你可以使用属性

checksums来覆盖全局设置。

    设置是逗号分隔的使用的校验和算法。
    在检测过程中(下载的时候)，找到的第一个校验和将被检测，然后就结束。这意外着如果你设置为"sha1, md5"，那么如果ivy发现了一个sha1文件，它将使用这个sha1来比较下载文件的sha1，并且如果比较是通过的，ivy将认为这个文件是正确的。如果没有发现sha1文件，ivy将查找md5文件。如果没有发现任何一个，将不进行检测。
    在发布过程中，任何例举出来的校验和算法都将被计算和上传。

    默认的校验和算法是"sha1, md5"。
    如果你想修改这个默认值，你可以设置变量ivy.checksums。因此想使校验和验证失效，你仅仅需要设置ivy.checksums为""。


十. 事件和触发器

    从1.4版本之后，当ivy完成依赖的解析和一些其他任务，ivy将在最重要的步骤前后发出事件。你可以使用ivy的api来监听这些事件，或者你甚至可以注册一个触发器在特定事件发生时来执行特定的动作。

    这是尤其强大而灵活的特性，例如它容许在依赖解析前执行依赖的构建，或者在依赖解析过程中精确地追踪发生的事情。

    更多关于时间和触发器的细节，请看本文档的配置章节中的触发器文档页面。

十一. 循环依赖

    从1.4版本之后，循环依赖可以是直接或者间接。例如，如果A依赖A，这是循环依赖，如果A依赖B而B依赖A，这也是循环依赖。

    在ivy1.4之前循环依赖会导致viy产生错误。到ivy1.4止，当ivy发现循环依赖时的行为可以通过循环依赖策略来配置。

    3个内建的策略可用：

    * ignore/忽略
        循环依赖仅仅用详细的信息警告进行标志。
    * warn / 警告
        和忽略相同，除非它们被标识为警告(默认)
    * error / 错误
        发现循环依赖时终止依赖解析

    查看配置页面来看如果配置你想使用的循环依赖策略。

十二. 缓存和变更管理

    ivy非常依赖本地缓存来避免过于频繁的访问远程仓库，从而节约网络带宽和时间。

1) 缓存类型

    ivy缓存由两个不同部分组成:

    * 仓库缓存
        仓库缓存是ivy保存从模块仓库下载的数据的地方，和一些关系到这些制品的元信息在一起，和他们的原始位置一样。

    * 解析缓存
    这个部分的缓存用来保存被ivy用来重用解析过程的结果的解析数据。
    这个部分的缓存每次完成一次新的解析时都被覆盖，并且决不能被多进程同时使用。

    通常只有一个解析缓存，但是你可以定义多个仓库缓存，每个解析器可以使用单独的缓存。

2) 变更管理

    为了加快依赖解析和缓存使用的方法，ivy默认认为修订本从不修改。因此一旦ivy在它的缓存中有这个模块(元数据或者制品)，ivy信任缓存，甚至不再查询仓库。大多数情况下这个优化时非常有用的，并且只要你遵循这个规范就不会引起问题: 修订本从不变更。除性能之外，还有几个好的原因来遵循这个原则。

    无论如何，取决于你当前的构建系统和你的依赖管理策略，你可能更愿意更新你的模块。有两种变更需要考虑:


    2.1) 模块元数据变更

    模块提供者不考虑经常优化模块元数据，他们更多的关注他们的api或者行为(如果他们甚至提供模块元数据)。我们不喜欢的事情经常发生：我们不得不更新模块元数据，一个依赖被遗忘了，或者另一个丢失了......

    在这种情况下，在你的依赖解析器上设置checkModified为"true"将是一个解决方案。这个标记告诉ivy需要检查模块的元数据相比较缓存是否被修改. ivy首先检查仓库中元数据的最后修改时间以决定只在必要时下载它，同样只在需要时更新它。


    2.2) 制品变更

    一些用户，尤其是从maven2过来的用户，喜欢使用一个特别的修订版本来处理经常变更的模块。在maven2中这个通常被称为SNAPSHOT(快照)版本，并且有一种主张认为这样可以帮助节约空间，因为只需要为开发时可能创建的大量的中间产物保留一个修订版本。

    ivy使用"changing revision"的概念来支持这种方法。changing revision就是这样：一个ivy认为随着时间推移始终可能变更的修订版本.为了处理这个，可以通过使用以来标签明确指定一个依赖为可以变更，或者在解析器上使用changingPattern 和changingMatcher 属性来知名那个修订版本或者修订版本组可以被认为是变更的。

    一旦ivy知道一个修订版本是变更的，它将遵循这样的原则来避免过于频繁的检查仓库：如果模块的元数据没有修改，它将认为整个模块(包括制品)没有修改。即使如果模块描述符文件已经修改，它将检查模块的发行数据来看这个是不是同一个修订版本的一个新的发行。然后如果发行数据被修改了，它将检查制品的最后修改时间戳，并相应的下载它们。

    因此如果你想使用变更修订版本，使用发布任务来发布你的模块，请小心更新发布数据，然后一切都会工作的很好。并且记住也要将你的解析器设置checkModified=true"。


十三. 路径处理

    作为一个依赖管理器，ivy有一系列的文件相关操作，大部分使用路径或者路径模式来在文件系统上定位文件。

    这些路径可以明确是的相对路径或者绝对路径。我们推荐经常使用绝对路径，这样你不必担心你的相对路径的基准路径是什么。ivy提供一些变量，可以被用来作为你的绝对路径的基准路径。例如，ivy有基准路径的概念，这个基本和ant一致。你可以使用变量ivy.basedir来访问这个基准目录。因此如果你有类似这样的路径：

${ivy.basedir}/ivy.xml

    你就得到了一个绝对路径。在设置文件中，你同样有一个名为ivy.settings.dir的变量指向你的设置文件所在的目录，这使得定义和这个目录相关的路径变得非常容易。

    如果你真的想使用相对路径，被用于实际定位文件的基准路径取决于相对路径在哪里被定义：

    * 在ivy文件中，路径是相对于ivy文件自身(在ivy文件中唯一可能的路径是用于配置包含申明)。
    * 在设置文件中，用于文件包含的路径(也就是属性文件装载和设置文件包含)是相对于设置文件所在的目录。所有其他路径除非明确记录否则必须是绝对路径。
    * 在ivy的ant任务和ivy参数或选项中，路径是相对于ivy基准路径的，当在ant中调用时这个路径就是ant的basedir路径一致。