我的组织正在研究在多项目配置中使用Apache Ivy进行依赖关系管理。我们有一个主项目（称之为MAIN），其中进行了大多数开发，还有一些帮助库项目（称为LIBPROJ），我们将这些项目保存在单独的存储库中。我们现在所做的是在库变更时为库项目构建jar，并将它们提交给主项目，但这是一个令人头痛的问题，导致项目膨胀。
看起来像使用像常春藤这样的东西很合适。我们设想使用我们的Jenkins服务器为LIBPROJ自动构建一个新的库jar并将其发布到ivy，然后使用“latest.integration”版本自动将最新版本的LIBPROJ引入MAIN。但是，如果我们必须一分为二，找出问题何时出现，这怎么可行呢？
我现在能想到的唯一方法就是在每次对LIBPROJ进行更改时更改我们在MAIN中依赖的LIBPROJ的版本，但这并不比检查jar本身好多了。
我担心这个的原因是因为在查看MAIN的旧版本的情况下，如果我只检查一个，那么将无法构建和运行，因为它正在请求最新版本，即使是我现在看的修订可能是几天/几周/几个月不同步。这会破坏任何类型的二分工具（比如在git或mercurial中），这是我真的不想做的事情。
答案 0 :(得分：1)
使用动态修订是常春藤的正常和强大功能。显然，您需要注意，因为当第三方项目引入不兼容的更改时， new 构建的依赖性可能会失败。
我的使用建议：
这里的重点是管理变革。动态修订仅用于内部依赖关系，只有关闭协作团队才能快速响应以构建开发构建引入的故障。
对于第三方开源依赖项，我建议设置显式版本并定期查看它们以进行升级。
最后，如果您对如何重现旧版本有疑虑，可用的解决方案是在剪切版本时提交已解析的ivy.xml的副本。 ivy deliver task可以执行此操作。
<ivy:deliver deliverpattern="ivy-resolved.xml" pubrevision="${version}" status="release"/>
不要忘记，如果您将模块发布到常春藤存储库中，那么解析的常春藤文件的副本也会存在。
答案 1 :(得分：0)
由于您的上一次评论，您不应该使用latest.integration。 恕我直言，最新的概念在同一个存储库中的项目之间特别有用，您希望将它们一起克隆/签出。
我在类似于你的情况下使用版本号依赖项。尽管如此，您可以自动更新版本号。
你可以创建一个（不是我最喜欢的）脚本：
1）构建LIBPROJ库
2）然后签出main并修改其依赖版本。
然而，在向同事们介绍IVY时，我并不鼓励这样做。当你想要一个新版本的LIBPROJ然后创建它并用一个明确的版本推送它。然后更改MAIN中的依赖项文件。
1）它不会膨胀二进制文件。
2）创建跟踪感，现在正在使用哪个版本。
3）版本控制。