如何对旧版本的代码使用ivy集成版本？ [英] How to use ivy integration versions against old versions of code?

问题描述

我的组织正在考虑在多项目配置中使用Apache Ivy进行依赖管理。我们有一个主要的项目（称之为MAIN），其中大部分开发都是在这里进行的，还有一些帮助程序库项目（称之为LIBPROJ），我们将它们保存在不同的存储库中。我们现在所做的是在图书馆项目发生变化时为它们建立罐子，并将它们提交给主项目，但这是一件非常头疼的事情，并导致项目膨胀。

<看起来像使用像常春藤这样的东西非常合适。我们设想使用我们的Jenkins服务器为LIBPROJ自动构建一个新的库jar并将其发布到ivy，然后使用latest.integration版本自动将最新版本的LIBPROJ引入MAIN。但是，如果我们不得不平分来发现问题何时突然出现，那么这将如何工作？

我现在想的唯一方法就是改变版本的LIBPROJ，我们依赖于MAIN，只要对LIBPROJ进行了更改，但这并不比检查jar本身好多少。

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

使用动态修订是常春藤的一个正常和强大的功能。显然，您需要注意，因为当第三方项目引入不兼容的更改时， new 构建的依赖关系可能会失败。

• latest.release ：由同一家公司（或合作公司）生产的模块。


• latest.integration ：由同一个项目中的其他团队生成的模块
  

这里的重点是管理变革。动态修订仅用于内部依赖关系，只有关闭协作团队可以快速响应以构建由开发版本引入的故障。

对于第三方开放源代码依赖项，我建议设置显式版本并定期检查它们是否需要升级。

最后，如果您担心如何重现旧版本，可用的解决方案是在裁剪版本时提交已解析的ivy.xml的副本。 常春藤递送任务可以执行此操作。

 < ivy：deliver deliverpattern =ivy-resolved.xmlpubrevision =$ {version}status =release/> ; 
  

不要忘记，如果您将模块发布到常青藤资源库中，解析的副本常春藤档案也将在那里。

My organization is looking into using Apache Ivy for dependency management in a multi-project configuration. We have a main project (call it MAIN) where most development takes place and a few helper library projects (call it LIBPROJ) which we keep in separate repositories. What we do right now is to build jars for the library projects when they change, and commit them to the main project, but this is a big headache and leads to project bloat.

It looks like using something like ivy is a good fit. We envision using our Jenkins server to automatically build a new library jar for LIBPROJ and publish it to ivy, then using a "latest.integration" version to automatically pull in the latest version of LIBPROJ into MAIN. But if we have to bisect to find out when an issue cropped up, how can this work?

The only way I can think to do this right now is to change the version of LIBPROJ we depend on in MAIN whenever a change is made to LIBPROJ, but that's not much better than checking in the jar itself.

The reason I'm concerned about this is because in the case of looking at old versions of MAIN, if I just check one out it won't be possible to build and run because it's requesting the latest build, even tho the revision I'm looking at right now might be days/weeks/months out of sync. This will break any kind of bisection tools (like in git or mercurial), which is something I really don't want to do.

解决方案

Using dynamic revisions is a normal and powerful feature of ivy. Obviously you need to take care because the dependencies of new builds can potentially fail when 3rd party projects introduce incompatible changes.

My recommendations on usage:

• latest.release : For modules produced by the same company (or collaborating companies).
• latest.integration : For modules produced by other teams within the same project

The point here is managing change. Dynamic revisions are only used for internal dependencies and only closing collaborating teams can react quickly enough to build failures introduced by development builds.

For 3rd party open source dependencies I recommend setting the explicit version and periodically review them for upgrade.

Finally, if you have concerns about how to reproduce older builds an available solution is to commit a copy of the resolved ivy.xml when cutting the release. The ivy deliver task can do this.

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

And don't forget that if you publish a module into your ivy repository, a copy of the resolved ivy file will be there as well.

这篇关于如何对旧版本的代码使用ivy集成版本？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！