我认为最令人惊讶的是这个功能默认为Maven和Gradle,但在Ant / Ivy版本中没有它的存在痕迹(请亲自看看!)。
我继承了一套使用Ant / Ivy作为构建/依赖系统的JVM组件。每个组件之间存在大量依赖关系,这意味着对其中一个组件进行更改通常会产生连锁反应,需要您更新Ivy依赖关系并发布新版本的上游依赖关系。
维护这些项目的旧团队通过将快照jar发布到快照存储库来处理本地开发。 我想用一个新范例替换这个范例,从而将快照发布到本地Ivy缓存/从本地Ivy缓存中解析。
我能够找到this very similar question,但发现答案有点缺乏细节(特别是完全拼接在一起的代码片段),部分原因是该问题缺少任何特定的代码示例。所以我在这里创建了一个SSCCE,并推出了2个GitHub repos:
fizzbuzz-model
作为依赖 我在这里寻找的是完全(即实际代码,而不是伪代码)更改(可能build.xml
,ivy.xml
或ivy-settings.xml
,或全部三个!),这将允许我使用以下本地开发/测试周期:
fizzbuz-model
进行了更改,并将更改在本地发布到常春藤缓存中,最好是作为快照版本(例如1.0.0-SNAPSHOT
或类似的)fizzbuzz-app
根目录内部运行ant resolve
,从缓存的快照中提取这些更改fizzbuzz-app
虽然不是硬性要求,但理想情况下,不必须手动管理版本号。也就是说,当我在本地发布fizzbuzz-model
时,它用相同的版本覆盖当前的二进制文件(再次,如fizzbuz-model-1.0.0-SNAPSHOT.jar
),而不是将buildnumber增加到,例如,{{ 1}}或类似的)。这样,我在本地测试时所要做的就是发布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)
开始克隆这些项目并按照自述文件进行操作。 任何人都可以找到我出错的地方吗?随意回答这里和/或提交PR,无论你喜欢哪个! 谢谢!
答案 0 :(得分:0)
该错误表明常春藤在本地构建工作区中找不到要发布的文件。这不是快照问题。
问题是here:
<ivy:publish resolver="local" pubrevision="1.0.0-SNAPSHOT" >
<artifacts pattern="dist/[artifact]-[revision].[ext]" />
</ivy:publish>
您已添加&#34;修订版&#34;在模式中但不幸的是,您在本地创建的jar与此命名约定不匹配。它缺少修订版,而且还有一个错字(应该是&#34; fizzbuzz&#34;,不是&#34; fizbuz&#34;):
<target name="dist" depends="clean,compile">
<jar jarfile="dist/fizzbuz-model.jar" basedir="build/main" />
</target>
我预测会有更多问题,因为您正在尝试配置常春藤来模拟Maven存储快照修订的方式。这需要Maven从未正式记录的其他元数据文件。我强烈建议将您发布的文件推送到Maven存储库管理器,以获取正确格式化的SNAPSHOT存储。
以下是从常春藤
向Maven回购发布人工制品的示例我已根据请求提交了Pull请求,我的建议是如何使用本地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>
注意:
像常春藤这样的依赖性经理来自Maven普遍受欢迎的时期(我记得当Maven 1.0受到普遍憎恨时),所以常春藤没有完全实现Maven&#39并不令人惊讶的工作流程。
Maven始终是一个高度自以为是的工具。令人困惑的是,它支持两种发布工件的方法。作为发布或快照。在我看来,这是在尝试使用Maven进行连续部署时导致最大摩擦的原因,其中所有版本都应考虑发布。但不可否认,Maven是分发所有基于Java的二进制文件的通用方法。 Maven存储库可以作为支持多种构建技术的单一集成点,Maven,Gradle或ANT / Ivy。
因此,首先需要接受快照开发工作流程对Maven来说非常特殊,据我所知,还没有任何其他存储库格式复制。
在其他存储库中,版本的版本号始终是唯一的。这适用于官方发布,候选发布或开发版本。另一方面,Maven快照永远不会完成。那是什么意思?如果我建立版本&#34; 1.0-SNAPSHOT&#34;今天,明天的依赖可能会完全不同。这是因为每个新的快照构建都会在幕后创建一个新的带时间戳的人工制品,只是覆盖以前存储的二进制文件。
Ivy有一种不同的机制来支持开发构建(不同并不意味着更好)。可以依赖于开发中的最新版本,但这将始终在构建时明确解决。当一个人工制品发布到常春藤存储库时,便捷的deliver任务就能够创建一个完全解析的常春藤文件。关于使用什么版本的依赖关系,从来没有任何歧义。
总而言之,首先要询问您是否确实需要支持快照工作流程。除非您打算使用Maven与其他团队集成,否则强制常春藤遵循其不支持的工作流程是不明智的。