如何构建存在依赖重叠的多项目构建结构？

嘿，这种每个项目都手动写一堆include配置的痛苦我太懂了！尤其是依赖重叠的时候，改一次依赖要改好几个settings.gradle，既麻烦又容易出错。针对你这种把所有模块和项目都集中在根目录的结构，我给你几个实用的优化方案，帮你彻底摆脱这个重复劳动的噩梦：

方案1：根目录集中管理所有模块（最推荐） #

把所有子模块和项目都在根目录的settings.gradle里一次性声明，这样每个子项目就不用再单独配置依赖的模块了，省心又高效。

操作步骤： #

• 打开根目录的settings.gradle，把所有模块和项目都加进去：

  include ':M1', ':M2', ':M3', ':M4', ':M5', ':M6'
  include ':P1', ':P2', ':P3', ':P4'
  

• 每个子项目的build.gradle里直接依赖对应的模块就行，比如P1的配置：

  dependencies {
      implementation project(':M1')
      implementation project(':M2')
      implementation project(':M3')
  }
  

• 像P3这种依赖其他项目的情况，直接在P3的build.gradle里写：

  dependencies {
      implementation project(':P1')
      implementation project(':M6')
  }
  

划重点：这种方式把配置集中在根目录，新增模块或调整依赖时只需要改一次根配置，子项目只需要关注自己的依赖声明，完全告别重复的include操作。

方案2：用复合构建保持项目独立性（适合未来拆分场景） #

如果之后你想把某些项目独立出去，但又不想放弃共享子模块的便利，Gradle的复合构建（Composite Builds）就很合适。不过针对你现在的结构，方案1已经足够，但可以先了解下：

简单配置示例： #

• 在P1的settings.gradle里，不用一个个include模块，直接引用根目录的构建：

  includeBuild('../') {
      dependencySubstitution {
          substitute module('com.yourgroup:M1') with project(':M1')
          substitute module('com.yourgroup:M2') with project(':M2')
          substitute module('com.yourgroup:M3') with project(':M3')
      }
  }
  

• 然后P1的build.gradle里就可以像依赖外部库一样写：

  dependencies {
      implementation 'com.yourgroup:M1'
      implementation 'com.yourgroup:M2'
      implementation 'com.yourgroup:M3'
  }
  

这种方式适合需要保持项目独立性，但又要共享子模块的场景，不过现在你的结构下方案1更直接。

方案3：自定义脚本批量处理（适合超大量模块/项目） #

如果你的模块和项目数量特别多，手动写include太麻烦，可以写个自定义脚本自动处理：

• 在根目录创建dependencies.gradle，定义好依赖映射：

  projectDependencies = [
      'P1': ['M1', 'M2', 'M3'],
      'P2': ['M1', 'M4', 'M5'],
      'P3': ['P1', 'M6'],
      'P4': ['P1', 'P2']
  ]
  

• 在根目录的settings.gradle里引入这个脚本，自动处理所有include：

  apply from: 'dependencies.gradle'
  
  // 先把所有用到的模块和项目都找出来
  def allItems = projectDependencies.keySet() + projectDependencies.values().flatten()
  allItems.unique().each { item ->
      include ":$item"
  }
  

这样以后新增依赖只需要修改dependencies.gradle，脚本会自动帮你处理include，完全不用手动敲。

总结 #

针对你现在的结构，方案1绝对是最直接、最易维护的选择——集中配置，一步到位，彻底解决重复include的问题。如果未来有更复杂的需求，再考虑方案2或3就好。

内容的提问来源于stack exchange，提问作者T. Marks