覆盖常春藤依赖项的修订 [英] Overriding an Ivy dependencies' revision

问题描述

我使用Apache Ivy处理库依赖关系.在我的公司中，我们有一个核心"项目，该项目会定期发布/版本化.然后，我们有许多针对特定客户的客户"项目.每个客户项目都使用核心项目的特定版本，我们在客户项目的ivy.xml中维护该版本.很好.

I use Apache Ivy for handling library dependency. In my company we have a "core" project which is released/versioned periodically. We then have many "customer" projects which are for a particular client. Each customer project uses a particular version of the core project which we maintain in the ivy.xml of the customer project. All fine.

有时，某些人想在本地更改核心，并使用特定项目测试更改.在这种情况下，他们将构建核心并将其发布到本地Ivy存储库，而不是共享的存储库.

Sometimes someone will want to change core locally and test the change with a specific project. In that instance they will build the core and publish it to a local Ivy repo, rather than the shared one.

为了获取此本地构建的版本，我是否需要确保本地构建的版本或核心发布的项目与ivy.xml中指向的x.y.z版本完全相同?还是有其他方法?我宁愿没有人需要摆弄ivy.xml(例如，将其更改为core-> Latest.integration)，因为这是偶然被检入到源代码管理中的一种更改.也许有一些方法可以覆盖ivy.xml中某个依赖项的修订，也许是在本地属性文件中?

In order to have this locally built version picked up do I need make sure the locally built version or core publishes with the exact same x.y.z version as the project is pointing at in ivy.xml? Or is there some other approach? I'd rather not have people required to fiddle with the ivy.xml (e.g. change it to core -> latest.integration) as that's the sort of change that gets checked in to source control by accident. Maybe there's some way of overriding the revision of a dependency in ivy.xml, perhaps in a local properties file?

推荐答案

在开发中，我始终将内部项目依赖项指定为"latest.integration"或"latest.release".这解决了不摆弄检查到源代码管理中的文件的问题.

In development I always specify my internal project dependencies as either "latest.integration" or "latest.release". This solves the problem of not fiddling with the files checked into source control.

好消息是，常春藤发布任务将为您解决动态修订号.检查发布到存储库中的 ivy.xml 文件，您会看到(发布时)最新的修订号已被自动替换.

The good news is that the ivy publish task will resolve dynamic revision numbers for you. Check the ivy.xml file that is published to your repository and you'll see the latest revision numbers (at time of publication) have been automatically substituted.

常春藤交付任务旨在在您的构建中为您执行此操作.当我需要一个已解析的常春藤文件来为我的模块生成一个Maven POM文件时，就可以使用它.

The ivy deliver task is designed to do this for you within your build. I use it when I need a resolved ivy file to generate a Maven POM file for my module.

例如:

<ivy:deliver pubrevision="??" status="release" deliverpattern="${build.dir}/ivy.xml"/>
<ivy:makepom ivyfile="${build.dir}/ivy.xml" pomfile="${build.dir}/pom.xml"/>

我的最后一个提示是使用常春藤版本号当您需要知道序列中的下一个版本号时. Ivy将根据已发布到ivy存储库中的内容进行解决(这比依赖属性文件的标准ANT内部版本号任务要灵活得多).

My final tip is to use the ivy buildnumber when you need to know the next version number in a sequence. Ivy will work this out based on what is already published to the ivy repository (Much more flexible that the standard ANT build number task which relies on property files).

因此，继续使用动态修订，并让ivy找出特定发行版中的实际版本号.

So continue to use dynamic revisions and let ivy work out the actual version numbers in a particular release.

这篇关于覆盖常春藤依赖项的修订的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！