Multiple settings gradle files for multiple projects building

前端 未结 6 1806
春和景丽
春和景丽 2020-11-29 21:03

I have the following project structure

-->Starnderd Location
        -->Project1 
           -->settings.gradle 
           -->build.gradle
              


        
6条回答
  •  死守一世寂寞
    2020-11-29 21:41

    as this topic crossed my daily work quite often now and the improvement (GRADLE-803) on it is still open, I would like to share my approach as well:

    At first sight, it looks similar to James Wald's answer but has one difference. You do not need to split your settings files somehow in the subproject. There is a clean way to do everything in the super project if that is acceptable for you. Normally your small sub projects should not have to care about the surrounding super projects. They include their sub dependencies and that's it. It should also be irrelevant how the module directory is named, in Wald's approach the module itself needs to know its directory name ('B') here:

    project.projectDir = new File("B/$relativeProjectPath")

    In contrast, usually, a super project knows its subprojects and directories well, because they could be git submodules for instance, which have well defined fix names which can be, from the super project perspective, safely referenced.

    That's my setup (using Gradle 2.4):

    Super Project
    ├── build.gradle
    ├── settings.gradle (include 'A' include 'B')
    ├── 
        ├── build.gradle
        ├── settings.gradle (include 'subA')
        ├── 
            ├── build.gradle
    ├── 
        ├── build.gradle
        ├── settings.gradle (include 'subB')
        ├── 
            ├── build.gradle
    

    In the super project settings.gradle you can now code the following:

    include 'A'
    include 'B'
    apply from: 'A/settings.gradle'
    apply from: 'B/settings.gradle'
    project(':subA').projectDir = new File(rootDir, 'A/subA')
    project(':subB').projectDir = new File(rootDir, 'B/subB')
    

    It still looks rather verbose (and still does not add real hierarchical behavior), but keeps the extra effort in the super project where you normally need to know everything about your contained modules anyways.

    The rest is pretty straight forward again.

    If you want to see my approach in practice, read section 5.) of this blog post, where I explicitly require this independence between the modules or just check out my github project on cross-language benchmarks. But be aware, you need a running native compiler toolchain like gcc or Clang to execute it ;)

    Hope this helps! Cheers Ben

提交回复
热议问题