具有重复的子项目名称的gradle混淆依赖关系

我有一个包含许多子项目和子子项目的gradle项目。我们发现了一个奇怪的条件，即是这样的：具有重复的子项目名称的gradle混淆依赖关系

这里是一个abrievated项目结构：

的build.gradle
settings.gradle
子1
- 共同
  - build.gradle
  - src
- 子一
  - 共同
    - 的build.gradle
    - SRC
  - 战争
    - 的build.gradle
    - SRC
SUB2

我的问题是 - 子：分1：子一：战争取决于：分1：常见的：子1：子a：common和：sub-1：sub-a：war无法构建，因为一些gradle如何看到两个依赖关系，但只保留一个，：sub-1：sub-a：common。运行gradle依赖会显示一条如下所示的行：sub-1：common - > sub-1：sub-a：common

看起来gradle在计算依赖关系时丢弃了一些东西，或者看起来太聪明，项目具有相同的“最终”名称，并且只在计算或蒸馏的依赖关系列表中选择其中的一个。

当然如果我重命名：sub-1：sub-a：common to：sub-1：sub -a：common1问题就消失了。 FWIW：共同的子项目都会生成jar文件 - 但它们设置的是特定的archivesBaseName，它们有很大不同。

确保“叶”子项目的所有名称都是全球唯一的缺点，有没有办法解决这个问题？（注意：可能会出现退化的代码/项目结构模式 - 但是，这出现在ant-> gradle转换项目中，我们不会在此阶段仅更改构建工具来更改结构。我欢迎评论改变结构;我确实想看看我能做些什么，我可以做什么，我有第一个）

来源

2015-02-11 fwelland

问题没有解决，但原因和解决办法更清楚一点。对于好奇的[这里]（http://forums.gradle.org/gradle/topics/dependency-substitution-wrong-with-more-than-one-sub-project-with-same-name）是gradle/forum post关于同样的事情 - 但更清楚的问题描述。和[这里]（https://github.com/fwelland/Submarine）是一个github项目，说明了这种情况。 – fwelland 2015-02-13 13:02:31

一个快速解决方案是使项目group名称独特。

当然，如果您需要从相同的项目发布工件，这可能是不可能的。但通常情况并非如此，并且更改group名称可以解决冲突。

project(':sub1:common').group = 'sub1.common' 
project(':sub1:suba:common').group = 'sub1.suba.common'

来源

2016-10-20 19:56:03 cmcginty

具有重复的子项目名称的gradle混淆依赖关系

回答

相关问题