1

我向 ivy.xml 添加了一个依赖项（我们将其命名为 A），该文件在 maven Central 中有一个 pom 文件。Ivy 使用 ibiblio 来解决 maven 依赖项。添加到 ivy.xml 的依赖项（A）具有传递依赖项（B）。到目前为止一切顺利。传递依赖（B）的依赖（C）不能被常春藤解析。

我在 ivy.xml 中定义 A 是这样的：

<dependency org="Z" name="A" rev="0.6-SNAPSHOT" conf="*->default"/>

在 B 的 pom 文件中，C 定义在编译和测试范围中，如下所示：

<dependency>
      <groupId>X</groupId>
      <artifactId>C</artifactId>
    </dependency>
    <dependency>
      <groupId>X</groupId>
      <artifactId>C</artifactId>
      <type>test-jar</type>
      <scope>test</scope>
</dependency>

当我在常春藤的缓存文件（~/.ivy2/cache/X/C/ivy-0.98.8-hadoop2.xml）中查看由常春藤解析的B的xml文件时，它看起来像这样：

<dependency org="X" name="C" rev="0.98.8-hadoop2" force="true" conf="test->runtime(*),master(*)"/>
<dependency org="X" name="C" rev="0.98.8-hadoop2" force="true" conf="test->runtime(*),master(*)">
  <artifact name="C" type="test-jar" ext="jar" conf="" m:classifier="tests"/>
</dependency>

由于这个原因，ivy 无法正确定义 C 作用域。作为记录，我无权修改 pom 文件，因为它们是第三方项目。我该如何解决？

4

1 回答 1

1

我回顾了nutch 项目的常春藤用法并道歉，但我的结论是它过于复杂，原因如下：

  • “编译”和“测试”目标分别调用 resolve 任务
  • 每个插件还调用一个常春藤解析任务
  • 维护类路径的复杂逻辑。可以使用cachepath任务和 ivy 配置来简化。
  • 构建插件不受常春藤管理（声纳，日食，老鼠）

我开始重构构建，但当我意识到我不了解主要 nutch 工件和插件之间的关系时不得不停止......（我发现NUTCH-1515很困难......浪费时间feed 插件缺少依赖项）。

我还注意到问题NUTCH-1371要求移除常春藤。如果不对当前代码库进行重大更改，这将是一个棘手的重构。我怀疑它必须是一个多模块构建，每个插件都列出了自己的依赖项。

总之，这项工作没有回答您的问题，但我认为我至少需要记录几个小时的分析结果 :-) 鉴于NUTCH-1371，我不知道您的项目是否能够容忍主要的 ivy 重构？

重构常春藤

以下是我到目前为止所取得的成就：

好处：

  • 显示所有配置的单一常春藤报告（新常春藤解析目标）
  • 安装 ivy 的新机制（新的ivy-install target）
  • 类路径使用 ivy 配置进行管理（请参阅 ivy 缓存路径任务的使用和ivy文件中的配置）
  • Eclipse、sonar 和 rat ANT 任务使用 ivy 自动安装（Eclipse 插件值得注意，因为它使用打包器解析器从 tar 存档下载和提取 jar）。

影响以下 Nutch 问题

  • NUTCH-1881：这种新方法删除了 resolve-test 和 resolve-default 目标，并使用 ivy 而不是 ${build.lib.dir} 管理类路径
  • NUTCH-1805：可以轻松地为作业目标设置一个单独的配置，并具有它自己的依赖项。
  • NUTCH-1755：我认为这是通过为 build.xml 指定名称来修复的（请参阅：diff）
于 2015-01-02T01:49:05.627 回答