我在理解如何在Java项目中有效地使用Ivy的动态修订时遇到了问题。
目前，我有以下布局：
lib-a
revision: 1.0.0
status: release
dependencies: none
lib-b
revision: 2.0.0
status: release
dependencies: lib-a, rev 1.0.0
project-a
revision: 3.0.0
status: release
dependencies: lib-b, rev 2.0.0
project-b
revision: 4.0.0
status: release
dependencies: lib-b, rev 2.0.0
这意味着我始终将状态保持为release并使用显式版本号。
如果我在开发过程中更改lib-a，请说lib-a，这非常痛苦。
我将更改保存在lib-a中，将常春藤文件中的修订更新为1.0.1以进行微小更改。然后我需要更新lib-b的依赖项来宣布lib-a的1.0.1版本。现在我可以更新lib-b和project-a的修订版，因为project-a是可执行文件，并且包含我需要运行的集成测试。
第二种方法是使用更新的依赖项重新发布lib-b但版本相同。这通常适用于命令行中的ant，但不适用于带有ivy-beans插件的NetBeans。他们仍然使用lib-b.的常春藤文件的缓存版本所以我需要清理到本地缓存以使其工作。
我在所有项目的SVN存储库中使用了一个通用的build-ivy.xml ant脚本。每个项目在项目的根目录中都有一个build.xml，大部分时间只包含build-ivy.xml。有时会添加或覆盖必要的任务。
我刚刚阅读了here和here解决方案可能正在使用动态修订版。
据我了解，我会将所有常春藤文件中的修订版设置为integration-latest，并将所有常春藤文件中的状态设置为integration。然后，常春藤将始终自动解析最新版本。
但是，我将模块的修订版设置为什么？完全省略吗？
我如何创建发布版本？我是否需要更改所有常春藤文件并将状态设置为release，或者在发布模块之前执行传递任务，并在可能的情况下将状态覆盖为release？
答案 0 :(得分：1)
我建议在Ivy阅读以下有关多模块项目的教程。
ANT版本传统上是庞大而单一的。您需要做的是模仿Maven将大型项目拆分为一系列较小版本的方法。每个子构建都将它的工件发布到常春藤的本地仓库中。
Ivy为这种结构提供了许多有用的任务：