Ivy无法解析依赖项的范围，该依赖项是可传递依赖项的依赖项

Question

我给ivy添加了一个依赖项（我们称之为a）。在maven central中具有pom文件的xml。Ivy使用ibiblio来解析maven依赖项。添加到常春藤中的依赖项（A）。xml具有可传递依赖项（B）。到目前为止，一切都很好。传递依赖（B）的依赖（C）不能用常春藤来解决。

我在常春藤上定义了一个新的名字。如下所示的xml：

<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>

当我在ivy的缓存文件（~/.ivy2/cache/X/C/ivy-0.98.8-hadoop2.xml）中查看由ivy解析的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>

由于这个原因，常春藤不能正确定义C作用域。郑重声明，我没有权限修改pom文件，因为它们是第三方项目。我怎么才能修好它？

Answer 1

我回顾了常春藤对nitch项目的使用，并道歉，但我的结论是，由于以下原因，它过于复杂：

• “compile”和“test”目标分别调用解析任务
• 每个插件还调用一个常春藤解析任务
• 用于维护类路径的复杂逻辑。可以使用cachepath任务和ivy配置简化
• 构建插件不是由ivy管理的（Sonar、eclipse、rat）

我开始重构构建，但当我意识到我不理解主要nutch工件和插件之间的关系时，我不得不停止。。。（我艰难地发现了NUTCH-1515……feed插件缺少依赖项，这是一个浪费时间的大问题）。

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

总之，这项工作并没有回答你的问题，但我认为我至少需要记录几个小时的分析结果：-）根据NUTCH-1371，我不知道你的项目是否能容忍主要的常春藤重构？

以下是我迄今为止所取得的成就：

• 中枢项目的私人"开发"分叉
• 与树干的差异

好处：

• 显示所有配置的单个常春藤报告（新常春藤解析目标）

影响以下Nutch问题

• NUTCH-1881：这种新方法删除了resolve测试和resolve默认目标，并使用ivy而不是${build.lib.dir}管理类路径
• NUTCH-1805：可以轻松地为作业目标设置一个单独的配置，该配置具有自己的依赖项
• NUTCH-1755：我认为这个问题可以通过为构建指定一个名称来解决。xml（参见：diff）