【问题标题】:Publishing to and resolving from Local Ivy Cache by Example通过示例发布到本地常春藤缓存并从本地常春藤缓存中解析
【发布时间】:2016-12-31 17:52:48
【问题描述】:

我认为这里最令人惊讶的是,这个功能默认嵌入到 Maven 和 Gradle 中,然而,在 Ant/Ivy 环境中没有它存在的痕迹(你自己看看!)。


我继承了一套使用 Ant/Ivy 作为构建/依赖系统的 JVM 组件。每个组件之间都有很多依赖关系,这意味着对其中一个组件进行更改通常会产生连锁反应,需要您更新 Ivy 依赖项并发布新版本的上游依赖项。

维护这些项目的旧团队通过将快照 jar 发布到快照存储库来处理本地开发。 我想用一个新的范式替换这个范式,将快照发布到本地 Ivy 缓存/从本地 Ivy 缓存中解析。

我能够找到this very similar question,但发现答案有点缺乏细节(特别是完全拼接在一起的代码 sn-p),部分原因是该问题缺少任何具体的代码示例。所以我在这里创建了一个SSCCE 并推送了2个GitHub repos:

  • fizzbuzz-model,一个定义数据模型的Java库(一些无意义的POJO)
  • fizzbuzz-app,一个简单的可执行 jar,依赖 fizzbuzz-model 作为依赖项

我在这里寻找的是确切(即实际代码,不是伪代码)更改(可能是build.xml,@ 987654328@ 或 ivy-settings.xml,或全部三个!)这将允许我使用以下本地开发/测试周期:

  1. 我对@9​​87654330@ 进行更改并将更改本地发布到Ivy 缓存,最好是作为快照版本(例如1.0.0-SNAPSHOT 或类似版本)
  2. fizzbuzz-app 根目录内部,我运行 ant resolve 从缓存快照中提取这些更改
  3. 现在我可以在fizzbuzz-app 中使用这些更改

虽然不是硬性要求,但我希望不必手动管理版本号。也就是说,当我在本地发布fizzbuzz-model 时,它覆盖 具有相同版本的当前二进制文件(再次,如fizzbuz-model-1.0.0-SNAPSHOT.jar),而不是将内部版本号增加到fizzbuzz-model-1.0.1-SNAPSHOT.jar 或类似的) .这样我在本地测试时所要做的就是发布fizzbuzz-model并解析fizzbuzz-app

目前,当我发布fizzbuzz-model 时,出现以下错误:

/Users/myuser/workspace/fizzbuzz-model/build.xml:52: impossible to publish artifacts for hotmeatballsoup#fizzbuzz-model;1.0: java.io.IOException: missing artifact hotmeatballsoup#fizzbuzz-model;1.0.0-SNAPSHOT!fizzbuzz-model.pom
    at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:225)
    at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:172)

要在本地复制,请克隆这两个项目并按照它们的自述文件,从 fizzbuzz-model 开始。 谁能发现我哪里出错了?随时在这里回答和/或提交 PR,无论你喜欢哪一个! 谢谢!

【问题讨论】:

  • 为什么投反对票?这个问题是关于主题的,不是骗人的,显示研究并且是SSCCE的教科书定义。
  • 我不是投反对票的人,但您没有确认我的回答,也没有处理您要求的拉取请求。

标签: java maven ant ivy


【解决方案1】:

该错误表示 ivy 在本地构建工作区中找不到要发布的文件。这不是快照问题。

问题是here:

<ivy:publish resolver="local" pubrevision="1.0.0-SNAPSHOT" >
  <artifacts pattern="dist/[artifact]-[revision].[ext]" />
</ivy:publish>

您已在模式中包含“修订”,但不幸的是您在本地创建的 jar 与此命名约定不匹配。它缺少修订版并且有一个错字(应该是“fizzbuzz”,而不是“fizbuz”):

<target name="dist" depends="clean,compile">
  <jar jarfile="dist/fizzbuz-model.jar" basedir="build/main" />
</target>

我预测会出现更多问题,因为您正在尝试配置 ivy 以模拟 Maven 存储快照修订的方式。这需要 Maven 从未正式记录的其他元数据文件。我强烈建议您将发布的文件推送到 Maven 存储库管理器,以获得正确格式的 SNAPSHOT 存储。

以下是将人工制品从 ivy 发布到 Maven 存储库的示例


建议的解决方案

我已按要求提交了拉取请求,并提出了关于如何使用本地 ivy 存储库而不是快照版本的建议:

总之,模型在每次新构建时都会发布一个新版本

<target name="publish" depends="clean,dist">

    <!-- Determine build number from previously published revisions -->
    <ivy:buildnumber resolver="local" organisation="${ivy.organisation}" module="${ivy.module}" revision="${target.release}"/>

    <!-- Resolve ivy dependencies and create a Maven POM file -->
    <ivy:deliver deliverpattern="dist/ivy.xml" pubrevision="${ivy.new.revision}" status="release"/>
    <ivy:makepom ivyfile="dist/ivy.xml" pomfile="dist/fizzbuzz-model.pom" />

    <!-- Publish the local repo. Defaults to ~/.ivy2/local -->
    <ivy:publish resolver="local" pubrevision="${ivy.new.revision}" >
        <artifacts pattern="dist/[artifact].[ext]" />
    </ivy:publish>
</target>

这在应用程序代码中用作动态依赖项,始终检索其他模块的最新发布版本。

<dependencies>
    <dependency org="hotmeatballsoup" name="fizzbuzz-model" rev="latest.integration" conf="compile->default" />
</dependencies>

注意事项:

  • 另外还会生成 POM 文件,严格来说,除非您将工件推送到 Maven 存储库,否则没有必要这样做。

背景

像 ivy 这样的依赖管理器来自 Maven 普遍流行之前的一段时间(我记得 Maven 1.0 被普遍讨厌的时候),所以 ivy 没有完全实现 Maven 的工作流程也就不足为奇了。

Maven 一直是一个高度固执己见的工具。令人困惑的是,它支持两种发布工件的方式。作为版本或快照。在我看来,这是在尝试使用 Maven 进行持续部署时造成最大摩擦的原因,所有版本都应考虑发布。但不可否认,Maven 是分发所有基于 Java 的二进制文件的通用方式。 Maven 存储库可以用作支持多种构建技术、Maven、Gradle 或 ANT/Ivy 的单个集成点。

因此,首先需要承认快照开发工作流程是 Maven 非常独特的,据我所知,还没有任何其他存储库格式复制过。

在其他存储库中,发布的版本号始终是唯一的。这适用于官方版本、候选版本或开发版本。另一方面,Maven 快照永远不会最终确定。我的意思是什么?如果我今天针对版本“1.0-SNAPSHOT”进行构建,那么明天的依赖关系可能会完全不同。这是因为每个新的快照构建都会在幕后创建一个新的带时间戳的人工制品,以覆盖之前存储的二进制文件。

Ivy 有不同的机制来支持开发构建(不同并不意味着更好)。可以依赖于开发中的最新版本,但这总是会在构建时明确解决。当一个人将一个人工制品发布到一个常春藤存储库时,那么方便的deliver 任务能够创建一个完全解析的常春藤文件。关于使用了哪个版本的依赖项,从来没有任何歧义。

因此,总而言之,首先确定您是否真的需要支持快照工作流程。除非您打算使用 Maven 与其他团队集成,否则强制 ivy 遵循其不支持的工作流程是不明智的。

【讨论】:

    猜你喜欢
    • 2011-06-05
    • 2011-09-07
    • 2011-04-12
    • 2013-07-07
    • 2013-09-23
    • 1970-01-01
    • 2016-05-28
    • 2012-09-11
    • 2010-11-20
    相关资源
    最近更新 更多