覆盖 Ivy 依赖项'修订
我使用 Apache Ivy 来处理库依赖性。在我的公司，我们有一个定期发布/版本控制的“核心”项目。然后，我们有许多针对特定客户的“客户”项目。每个客户项目都使用我们在客户项目的 ivy.xml 中维护的核心项目的特定版本。一切都很好。
有时有人会想要在本地更改核心并使用特定项目测试更改。在这种情况下，他们将构建核心并将其发布到本地 Ivy 存储库，而不是共享存储库。
为了获取这个本地构建的版本，我是否需要确保本地构建的版本或核心发布的 xyz 版本与项目在 ivy.xml 中指向的完全相同？或者还有其他方法吗？我不想让人们需要摆弄 ivy.xml（例如将其更改为 core ->latest.integration），因为这是意外签入源代码管理的那种更改。也许有某种方法可以覆盖 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.
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.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在开发过程中，我总是将内部项目依赖项指定为“latest.integration”或“latest.release”。这解决了不摆弄签入源代码管理的文件的问题。
好消息是 ivy publish 任务将为您解决动态修订号。检查发布到存储库的 ivy.xml 文件，您将看到最新的修订号（发布时）已被自动替换。
ivy deliver 任务旨在执行此操作你在你的构建中。当我需要解析的 ivy 文件来为我的模块生成 Maven POM 文件时，我会使用它。
例如：
我的最后一个技巧是使用 ivy buildnumber 当您需要知道序列中的下一个版本号时。 ivy 将根据已发布到 ivy 存储库的内容来解决此问题（比依赖属性文件的标准 ANT 版本号任务更加灵活）。
因此，继续使用动态修订并让 ivy 计算出特定版本中的实际版本号。
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.
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.
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.
For example:
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).
So continue to use dynamic revisions and let ivy work out the actual version numbers in a particular release.