0

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

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

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

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

4

2 回答 2

1

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

我的使用建议：

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

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

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

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

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

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

于 2012-07-27T22:37:04.560 回答
0

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

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

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

1) 构建 LIBPROJ 库

2）然后检查主要并修改其依赖版本。

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

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

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

2) 为现在正在使用哪个版本创建跟踪感。

3) 版本控制。

于 2012-07-27T21:24:07.630 回答