当前位置: 首页 > 知识库问答 >
问题:

解决与文件系统库(即不是maven或ivy)的渐变传递依赖冲突

劳夕
2023-03-14

我们有一个具有依赖项的java项目,其外观如下所示。

A -> B -> httpcore-4.0.1
\         
 C -> httpcore-4.1.3

因此A中存在传递依赖冲突。gradle文档说解决策略是选择最新的(http://gradle.org/docs/current/userguide/dependencymanagement.html)。但是,由于函数签名的差异,我们会出现编译错误,所以似乎没有选择最新的。我见过各种排除方法,但不确定当我们使用基于文件系统的依赖项库(而不是maven或ivy)时,它们是如何应用的。Eclipse似乎可以很好地解决这个问题,并编译但分级barf。我试过各种形式的:

configurations {
    all*.exclude group:'org.apache', name: 'httpcore', version:'4.0.1'
    all*.exclude group:'org.apache.httpcomponents', name: 'httpcore', version:'4.0.1'
}

我错过了什么?

我用的是1.0级里程碑-8A

共有1个答案

陆信瑞
2023-03-14

只是还没完成。参见http://forums.gradle.org/gradle/topics/resolve_gradle_transitive_dependency_conflict_with_file_system_libs_ie_not_maven_ivy

您必须使用本地或远程回购。

 类似资料:
  • 我正在使用文件,告诉sbt 0.13.5从哪个存储库中检索。该文件仅包含和一个存储库,其自定义布局与标准sbt存储库非常相似,并表示和可选字段。 在解决项目的依赖关系时,我注意到了一些奇怪的行为: 解析精确的依赖关系很好 如您所见,请明确提及回购布局模式。 我很困惑,因为解析器可以很好地处理通配符依赖项以外的任何东西。我试着翻遍常春藤文档,想弄清楚某些解析器(比如我使用的解析器)是否没有实现某些类

  • 我试图从gradle构建中排除嵌套的传递依赖项。依赖结构看起来像 org.apache.beam:beam-sdks-java-core:2.33.0-自定义 我按照gradle exclude的公认解决方案排除了依赖性,但它对我不起作用。 这不排除依赖项。当我将其更改为时,依赖项仍然没有被排除。 关于如何排除这种依赖关系的任何建议?它在旧版本中拉动。

  • 几天来,当根依赖来自我的本地存储库时,我试图让apache常春藤解决我在ivy.xml中声明的依赖关系,但失败了。我的公共存储库(maven)中的根依赖关系工作得很好,甚至在我编辑ivy.xml指向本地存储库中模块的依赖关系时也能工作。但是本地存储库的传递依赖解决方案将不起作用。我检查了缓存中一个本地模块的解析ivy.xml,依赖部分已经被清除了!有什么我必须做的吗? 这是我的ivysetting

  • 问题内容: 假设我有四个项目: 项目A(依赖于B和D) 项目B(依赖于D) 项目C(依赖于D) 项目D 在这种情况下,如果我运行项目A,则Maven将正确地解决对D的依赖关系。如果我理解正确,则Maven始终以最短的路径获取依赖关系。由于D是A的直接依赖项,因此将使用B内指定的D而不是D。 但是现在假设这种结构: 项目A(依赖于B和C) 项目B(依赖于D) 项目C(依赖于D) 项目D 在这种情况下