ivy中文参考文档(7)-最佳实践(下)

核心提示： * 发布的可能性如果你描述一个自身可以被复用的模块的依赖，你希望将它发布到仓库，ivy中文参考文档(7)-最佳实践(下)(3)，在这种情况下只有你有单独的ivy文件发布才有可能，* 更灵活内联依赖仅仅能用于表达一个依赖并且只能一个，但是我们不会假装我们掌握了依赖管理或者甚至是ivy使用的唯一真理

* 发布的可能性

如果你描述一个自身可以被复用的模块的依赖，你希望将它发布到仓库。在这种情况下只有你有单独的ivy文件发布才有可能。

* 更灵活

内联依赖仅仅能用于表达一个依赖并且只能一个。ivy文件可以用于表达更复杂的依赖。

另一方面，以下情况使用内联依赖非常有用：

* 你希望在你的ant构建中使用定制任务

没有ivy的情况下，通常或者是复制定制任务的jar到ant的lib目录下，这需要维护你的工作站安装，或用恰当的classpath通过手工复制或者下载任务定义(taskdef)，这个更多。但是如果你有多个定制任务，或者如果他们有自己的依赖，这将变得非常麻烦。通过内联依赖来使用ivy是解决这个问题的一种优雅的方式。

* 你希望容易部署应用

如果你已经构建了你的应用而它的模块使用ivy，那么用你的ivy仓库来下载你的应用和它所有的依赖到本地文件系统来准备执行是非常容易的。如果你同时将你的配置文件作为制品放置在你的仓库(也行打包为zip文件)，整个安装过程可以依赖ivy，简化你的仓库中可以得到的应用的任意版本的自动安装。

7) 雇用专家

在软件开发时间中构建和依赖管理通常被是。我们经常看到开发人员在他们有时间的时候实现构建管理。即使这种方式看上去短期内可以节约时间和钱，长期看它通常转为一个非常坏的选择。构建软件不是一个简单的任务，当你想保证自动化，被测试过，完全可重现的构建，发布和安装。另一方面，一旦一个好的可以满足你非常特殊的构建系统被安装好，它可以只依赖很少的对此有良好理解的人，就可以做到持续的质量保证。

因此雇用一个构建和依赖的专家来分析和改进你的构建和发布系统在大多数时间是一个非常好的选择。

8) 反馈

这些最佳实践反映的是我们自己的经验，但是我们不会假装我们掌握了依赖管理或者甚至是ivy使用的唯一真理。

因此请不要客气地在这个页面上面评论来增加你自己的经验反馈，建议或者主张。