如何针对旧版本的代码使用 ivy 集成版本？答案

【问题标题】：How to use ivy integration versions against old versions of code?如何针对旧版本的代码使用 ivy 集成版本？
【发布时间】：2012-07-26 07:23:42
【问题描述】：

我的组织正在研究在多项目配置中使用 Apache Ivy 进行依赖管理。我们有一个主要项目（称为 MAIN）和一些帮助库项目（称为 LIBPROJ），我们将它们保存在单独的存储库中。我们现在要做的是在库项目发生变化时为它们构建 jar，并将它们提交到主项目，但这很头疼，并导致项目膨胀。

看起来像使用常春藤这样的东西很合适。我们设想使用我们的 Jenkins 服务器自动为 LIBPROJ 构建一个新的库 jar 并将其发布到 ivy，然后使用“latest.integration”版本自动将最新版本的 LIBPROJ 拉入 MAIN。但是，如果我们必须一分为二才能找出问题出现的时间，这怎么能行呢？

我现在能想到的唯一方法是在对 LIBPROJ 进行更改时更改我们在 MAIN 中依赖的 LIBPROJ 的版本，但这并不比检查 jar 本身好多少。

我担心这个的原因是因为在查看旧版本的 MAIN 的情况下，如果我只检查一个，它将无法构建和运行，因为它正在请求最新的构建，即使是我现在正在查看的修订可能几天/几周/几个月不同步。这将破坏任何类型的二分工具（如 git 或 mercurial），这是我真的不想做的事情。

【问题讨论】：

标签： git mercurial ivy bisect

【解决方案1】：

使用动态修订是 ivy 的正常且强大的功能。显然，您需要小心，因为当 3rd 方项目引入不兼容的更改时，new 构建的依赖关系可能会失败。

我的使用建议：

latest.release：适用于同一公司（或合作公司）生产的模块。
latest.integration ：用于同一项目中其他团队制作的模块

这里的重点是管理变更。动态修订仅用于内部依赖关系，只有关闭协作团队才能足够快地做出反应，以构建由开发构建引入的失败。

对于第 3 方开源依赖项，我建议设置显式版本并定期检查它们以进行升级。

最后，如果您担心如何重现旧版本，可用的解决方案是在发布版本时提交已解决的 ivy.xml 的副本。 ivy deliver task 可以做到这一点。

<ivy:deliver deliverpattern="ivy-resolved.xml" pubrevision="${version}" status="release"/>

不要忘记，如果您将模块发布到您的 ivy 存储库中，那么解析后的 ivy 文件的副本也会在那里。

【讨论】：

【解决方案2】：

由于您的最后一句话，您不应该使用 latest.integration。恕我直言，最新概念在相同存储库中的项目之间特别有用，您希望将它们一起克隆/签出。

在与您类似的情况下，我正在使用版本号依赖项。不过，您可以自动更新版本号。

你可以创建一个脚本（不是我最喜欢的）：

1) 构建 LIBPROJ 库

2) 然后检查 main 并修改其依赖版本。

然而，我在向同事介绍 IVY 时并不鼓励这样做。当您想要一个新版本的 LIBPROJ 时，请创建它并以明确的版本推送它。

然后更改 MAIN 中的依赖文件。

1) 它不会膨胀二进制文件。

2) 创建当前正在使用哪个版本的跟踪感。

3) 版本控制。

【讨论】：