Ivy无法解决依赖的范围，依赖关系是传递依赖的依赖关系 [英] Ivy can not resolve the scope of a dependency which is a dependency of a transitive dependency

问题描述

我将依赖项（我们将其命名为A）添加到ivy.xml，它在maven central中有一个pom文件。 Ivy使用ibiblio来解析maven依赖项。添加到ivy.xml的依赖项（A）具有传递依赖性（B）。到目前为止一直很好。传递依赖关系（B）的依赖关系（C）无法通过常春藤来解决。

I add a dependency(let's name it as A) to ivy.xml which has a pom file in maven central. Ivy uses ibiblio for resolving the maven dependencies. The dependency(A) which is added to ivy.xml has a transitive dependency(B). So far so good till here. The dependency(C) of transitive dependency(B) can not be resolved by ivy.

我在ivy.xml中定义了A，如下所示：

I defined A in ivy.xml like this:

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

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

In pom file of B, C is defined both in compile and test scopes like below:

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

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

When I look the xml file of B which is resolved by ivy in ivy's cache file(~/.ivy2/cache/X/C/ivy-0.98.8-hadoop2.xml), it looks like this:

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

For this reason, ivy can not define C scopes correctly. For the record, I don't have permissions to modify the pom files as they are third party projects. How can I fix it ?

推荐答案

我回顾了 nutch项目并道歉，但我的结论是，由于以下原因，它过于复杂：

I reviewed the ivy usage of the nutch project and apologies but my conclusion is that it's overly complex for the following reasons:

• compile和test目标正在发出对解析任务的单独调用。


• 每个插件也调用常春藤解析任务


• 复杂逻辑维护类路径。可以使用 cachepath 任务和常春藤配置进行简化。


• 构建插件不受常春藤管理（声纳，日食，老鼠）

• "compile" and "test" targets are issuing separate calls to the resolve task
• Each plugin is also calling an ivy resolve task
• Complex logic for maintaining classpaths. Could be simplified using the cachepath task and ivy configurations.
• Build plugins are not managed by ivy (Sonar, eclipse, rat)

我开始重构构建，但当我意识到我不理解主要的nutch工件和插件之间的关系时不得不停止...（我发现 NUTCH-1515 艰难的方式......大浪费时间饲料插件缺少依赖性。）

I started to refactor the build, but had to stop when I realised that I didn't understand the relationship between the main nutch artifact and the plugins... (I discovered NUTCH-1515 the hard way... big time-waster The feed plugin has missing dependencies).

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

I also noticed issue NUTCH-1371 calling for the removal of ivy. This would be a tricky refactoring without significant change to the current codebase. I suspect it would have to be a multi-module build with each plugin listing its own dependencies.

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

In conclusion, this work does not answer your question, but thought I needed to at least document the result of a few hours analysis :-) In light of NUTCH-1371 I don't know if your project will tolerant major ivy refactoring?

以下是我目前取得的成果：

Here follows what I achieved so far:

• 私人开发荷兰项目的分支


• 与主干的差异化

福利：

• 显示所有配置的单一常春藤报告（新< a href =https://github.com/myspotontheweb/nutch/blob/development/build.xml#L55\"rel =nofollow>常春藤 - 解决目标）


• 安装常春藤的新机制（New 常春藤安装目标）


• 类路径是使用常春藤配置管理（请参阅使用常春藤缓存路径任务和<常春藤文件中的href =https://github.com/myspotontheweb/nutch/blob/development/ivy.xml#L27\"rel =nofollow>配置）


• 使用常春藤自动安装Eclipse，声纳和鼠标ANT任务（Eclipse插件值得注意，因为它使用打包程序解析程序从tar存档下载并解压缩jar。）

• Single ivy report showing all configurations (New ivy-resolve target)
• New mechanism for installing ivy (New ivy-install target)
• Classpaths are managed using ivy configurations (See use of ivy cachepath task and configurations in ivy file)
• Eclipse, sonar and rat ANT tasks automatically installed using ivy (The Eclipse plugin is noteworthy as it uses a packager resolver to download and extract jar from a tar archive).

影响以下Nutch问题

Impacts the following Nutch issues

• NUTCH-1881 ：这种新方法删除了解决测试和解析默认目标并管理了cl asspaths使用常春藤代替$ {build.lib.dir}


• NUTCH-1805 ：可以使用自己的依赖项轻松为作业目标设置单独的配置。


• NUTCH-1755 ：我认为通过为build.xml指定一个名称来解决这个问题（参见： diff ）

• NUTCH-1881 : This new approach removes resolve-test and resolve-default targets and manages the classpaths using ivy instead of the ${build.lib.dir}
• NUTCH-1805 : Can easily setup a separate configuration for the job target with it's own dependencies.
• NUTCH-1755 : I think this one is fixed by assigning a name to the the build.xml (see: diff)

这篇关于Ivy无法解决依赖的范围，依赖关系是传递依赖的依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！