【问题标题】:What's wrong with this Ivy changingPattern / SNAPSHOT configuration?这个 Ivy changedPattern / SNAPSHOT 配置有什么问题?
【发布时间】:2013-01-04 21:34:35
【问题描述】:

更新快照依赖项时,我无法让 Ivy 更新缓存。解析器(具有以下设置:

<url name="xxx" m2compatible="false" 
     checkmodified="true" changingMatcher="regexp" 
     changingPattern=".*-SNAPSHOT.*">

一个示例工件文件名(在 Artifactory 中)是:

my-jar-1.999-SNAPSHOT.jar

详细的 Ant 解析日志包括:

[NOT REQUIRED] com.myorg#my-module;1.999-SNAPSHOT!my-jar.jar

工件上没有 POM。

解析器位于链式解析器下方;他们都有所有相关的属性集。我已阅读 https://issues.apache.org/jira/browse/IVY-938https://issues.apache.org/jira/browse/IVY-1221,包括所有 cmets 和 AFAICT(可能是错误的!)没有任何解决方法是相关的。

我是否应该放弃快照而只使用具有“integration.latest”动态版本依赖的显式版本?我担心当我们为多个主要版本进行集成构建时,这可能最终会失败。此时,我们需要将主要版本拆分到单独的存储库中,或者将主要内部版本号放在工件名称中,或者同样笨拙的东西,以使“integration.latest”工作。

【问题讨论】:

  • 我看到你已经修改了这个问题...快照修改是一个特殊的 Maven 功能。您指定 1.2.3-SNAPSHOT,它会神奇地转换为具有时间戳版本号的内部存储文件:1.2.3-201301210911。查看您的存储库并查看检索实际文件所需的 URL。
  • @MarkO'Connor 该仓库的名称没有时间戳,如我上面所示:my-jar-1.999-SNAPSHOT.jar。
  • 我很抱歉专注于 Maven... 它引入了快照的概念,当我认为 ivy 的“latest.release”和“latest.integration”方法在人们如何处理方面更加标准时管理他们的修订号。

标签: ivy artifactory


【解决方案1】:

在与 Maven 存储库管理员交谈时,我不喜欢使用 url 解析器。 问题是 Maven 对快照修订有特殊且相当独特的处理...... url 解析器更适合用于 ivy 存储库。

我使用 Nexus,但以下内容也应该适用于 Artifactory。以下设置文件设置 Maven Central 和我的两个托管存储库(Maven 存储库有两种风格,发布或快照):

<ivysettings>
    <settings defaultResolver="repos" />
    <resolvers>
        <chain name="repos">
            <ibiblio name="central" m2compatible="true"/>   
            <ibiblio name="my-releases" m2compatible="true" root="https://myhost/releases"/>   
            <ibiblio name="my-snapshots" m2compatible="true" root="https://myhost/snapshots"/>   
        </chain>
    </resolvers>
</ivysettings>

您会注意到我正在使用ibilio 解析器,它具有破译 Maven 特殊快照处理的内部逻辑。

当我需要快照修订时,我认为明确声明如下:

<ivy-module version="2.0">
    <info organisation="myOrg" module="Demo"/>
    <dependencies>
        <dependency org="myOrg" name="myModule" rev="2.7-SNAPSHOT"/>
        ..
    </dependencies>
</ivy-module>

在后台,ibilio 解析器正在读取 Maven 存储库元数据文件,以确定应从快照存储库中获取哪个带时间戳的工件。

更新

我建议阅读以下演示文稿:

它很好地概述了将发布与开发构建(或快照)分开的 Maven 哲学。它还解释了 Maven 非常笨拙的方面之一...发布工件的两种不同方式...

我怀疑您正在尝试做的是按照作者的思路,即设置 CD 管道。在这种情况下,每个构建都是一个潜在的版本,应该被这样对待(没有快照允许的动态依赖关系)。

我建议将快照限制为仅限开发人员构建。仅部署候选版本。这种方法的问题在于管理大量的发布。一些存储库管理器(Nexus、Artifactory、Archiva)提供“暂存”功能,可以验证或丢弃未通过质量关卡的版本。

更新 2

如果您使用 ivy 将快照发布到 Maven 存储库中,那么有几个问题:

在我看来,时间戳文件首先是使用快照的杀手级功能之一。使用 ivy 只能提供最新的文件(覆盖之前的最新文件)。

有解决这些问题的变通方法:

  1. 正如第二个链接中所建议的,您可以完全忽略元数据(将“useMavenMetadata”属性设置为 false)并默认返回 ivy 比较文件名的旧机制。这只解决了常春藤客户的问题。
  2. 存储库管理器应该能够重新生成元数据文件(Nexus 至少有一个任务来执行此操作)。
  3. 使用 Maven ANT 任务。

最后一个建议并不像看起来那么疯狂。首先,这是我知道的唯一支持时间戳快照的方法,其次,Maven 客户端似乎做了很多额外的处理(更新模块元数据),这些处理基本上没有记录。

【讨论】:

  • 谢谢,但我们根本没有使用 Maven。除了 ivy.xml 文件之外,没有任何 poms 和重要的元数据。
  • @EdStaub Nexus、Artifactory、Archiva 是最初设计用于托管 Maven 存储库的产品。 Ivy 了解这些存储库用来存储其数据的 Maven 2(或 M2)存储库格式。 Ivy 能够与这些存储库进行本地对话。所以是的,客户端没有 POM(功能上由 ivy.xml 文件替换)服务器端一切都是基于 Maven 的。查看用于存储快照的存储库。您会发现列出时间戳修订的特殊“maven-metadata.xml”文件。 ibilio 解析器了解如何读取这些文件。
  • 非常感谢。元数据文件不存在,但这可能是因为我设置了 m2compatible="false" 和/或因为我使用了 url 解析器(因为我们需要一些 Maven 不支持的命名模式灵活性)。我会看看我能不能让它工作。
  • @EdStaub 要检查的另一件事... Artifactory 在管理存储库布局的方式上更加灵活。也许您正在访问的存储库未配置为具有 M2 布局?值得检查....我个人建议对事实上的行业标准进行标准化。使基于 Maven 的构建能够访问您的工件。
  • 我主要依赖 Ivy 和 Artifactory 文档以及 Jira 的文档,这些文档通常反映了与 Maven 和 Nexus 的差异。不,我们不是在尝试实施持续交付管道。开发人员和 Jenkins 都使用快照构建。我不确定您所说的“部署”是什么意思-如果您的意思是“在开发人员之外发布”,是的,我们不会对快照执行此操作。这一切都太离谱了——我只想让快照按照Ivy docs 中的记录工作,这可能意味着它只适用于 ibiblio。
【解决方案2】:

经过几天的奋斗......

问题在于

checkmodified="true" changingMatcher="regexp"

要在 上工作,它必须在层次结构行中的每个解析器上 - 所有父 解析器和 底部的解析器。

【讨论】:

  • 非常感谢您的提示!我发现明确的 changing="true" 依赖也带来了补救,但这种解决方法更好。不幸的是,解析器链上的checkmodified="true" 增加了总检索时间,因为额外的网络往返不会更改来自其他存储库的工件。正如stackoverflow.com/questions/9426357/apache-ivy-chain-tag 所建议的那样,这鼓励我完全避免使用链式解析器。这使得检索速度更快,也有效地消除了相关问题和解决问题的需要。
猜你喜欢
  • 2016-02-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-02-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多