常春藤无法解决依赖关系的范围，它是传递依赖关系的依赖关系

Question

我在ivaven.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文件，因为它们是第三方项目。我该如何解决？

Answer 1

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

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

我开始重构构建，但是当我意识到我不了解主要的坚果工件和插件之间的关系时不得不停下来……（我发现NUTCH-1515的方法很艰辛……浪费大量时间。
feed插件缺少相关性）。

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

总之，这项工作不能回答您的问题，但是我认为我至少需要记录几个小时的分析结果：-)鉴于NUTCH-1371，我不知道您的项目是否可以忍受主要的常春藤重构？

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

• 坚果项目的私人“发展”分支
• 与树干的差异

好处：

• 单个常春藤报告显示所有配置（新的常春藤解决目标）
• 安装常春藤的新机制（新的常春藤安装目标）
• 使用ivy配置管理类路径（请参阅ivy文件中ivy cachepath任务和配置的使用）
• 使用常春藤自动安装的Eclipse，声纳和大鼠ANT任务（Eclipse插件值得注意，因为它使用打包程序解析器从tar存档中下载和提取jar）。

影响以下Nutch问题

• NUTCH-1881：此新方法删除了“解析测试”和“解析默认”目标，并使用常春藤代替$ {build.lib.dir}管理类路径。
• NUTCH-1805：可以凭借自己的依赖关系轻松地为作业目标设置单独的配置。
• NUTCH-1755：我认为可以通过为build.xml分配一个名称来解决此问题（请参阅：diff）