我在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文件,因为它们是第三方项目。我该如何解决?
我回顾了常春藤项目和道歉的用法,但我的结论是它过于复杂,原因如下:
我开始重构构建,但是当我意识到我不了解主要的坚果工件和插件之间的关系时不得不停下来……(我发现NUTCH-1515的方法很艰辛……浪费大量时间。 feed插件缺少相关性)。
我还注意到问题NUTCH-1371要求移除常春藤。如果不对当前代码库进行重大更改,这将是一个棘手的重构。我怀疑这将是一个多模块构建,每个插件都列出了自己的依赖关系。
总之,这项工作不能回答您的问题,但是我认为我至少需要记录几个小时的分析结果:-)鉴于NUTCH-1371,我不知道您的项目是否可以忍受主要的常春藤重构?
这是我到目前为止所取得的成就:
好处:
影响以下Nutch问题