Plusieurs paramètres gradle fichiers pour de multiples projets de construction

J'ai été en mesure de résoudre ce problème en un temps relativement propre. Des améliorations sont certainement les bienvenus!

Bien que Gradle ne prend pas en charge plusieurs settings.gradle les scripts en dehors de la boîte, il est possible de créer des sous-projets, chacun avec leur propre settings.gradle fichier. Disons que vous avez multi-projet qui dépend de la multi-projet B, chacune avec leurs propres sous-projets. Votre structure de répertoire pourrait ressembler à:

A
- settings.gradle
- foo
- faz
\ B
  - settings.gradle
  - bar
  - bap

Hors de la boîte, Gradle attend A/settings.gradle à ressembler à quelque chose comme ceci:

include ':foo', ':faz', 'B:bar', 'B:bap'

Le problème, c'est que chaque fois que B ajoute un nouveau projet, A/settings.gradle doit aussi changer, même si le nouveau projet est uniquement utilisée par B. Pour éviter cette situation, vous pourriez essayer de apply B/settings.gradle dans A/settings.gradle au lieu d'ajouter des déclarations redondantes:

apply from: 'B/settings.gradle'
include ':foo', ':faz'

Si vous essayez cela, vous verrez que Gradle échoue, car il génère le mal projectDir pour :bar et :bap. Il suppose à tort que B contient sont relatifs à settingsDir qui se trouve être A/ quand Gradle est invoquée à partir de cette racine du projet. Pour corriger cela, vous pouvez ajouter un autre script comme B/settings-parent.gradle (le nom exact n'est pas significatif):

apply from: 'settings.gradle'

rootProject.children.each { project ->
    String relativeProjectPath = project.projectDir.path.replace(settingsDir.path, "")
    project.projectDir = new File("B/$relativeProjectPath")
}

Cette bandes settingsDir.path et préfixes le chemin avec B/. Cela peut être étendu à plusieurs couches de settings[-parent].gradle fichiers en ayant chaque couche d'ajouter lui-même sur le chemin. Maintenant, vous allez appliquer ce script à A/settings.gradle:

apply from: 'B/settings-parent.gradle'
include ':foo', ':faz'

Avec ce régime, des nouveaux projets B ne sont pas inutilement pause A/settings.gradle et tous les projets peuvent être utilisées sans explicitement référence au B du sous-projet. Par exemple, si ':foo' voulu utiliser 'B:bap', il peut simplement déclarer:

compile project(':bap')

Si vous utilisez Gradle 3.x, essayez includeBuild():
https://docs.gradle.org/current/userguide/composite_builds.html

//settings.gradle
includeBuild './Project1'
includeBuild './Project2'

Si vous utilisez Gradle 2.x, j'ai écrit une démonstration de cette fonction. Espérons, vous aidera à:
https://github.com/xujiaao/gradle-composite-build-demo

//settings.gradle
def includeProject(String path, Closure closure) {
    ...

    apply {
        from ...
        to new SettingsProxy(...)
    }
}

class SettingsProxy {
    ...

    public getRootProject() { ... }

    public void include(String... paths) {
        for (String path : paths) {
            if (!mProjectSpec.accept(path)) {
                continue
            }

            def descendantPath = generateDescendantPath(path)
            mSettings.include(descendantPath)

            def descendantProjectDir = new File(mProject.projectDir, path.replace(':', '/'))
            mSettings.project(descendantPath).projectDir = descendantProjectDir
        }
    }
}

comme ce sujet a traversé mon travail quotidien assez souvent maintenant et à l'amélioration ( GRADLE-803 ), il est toujours ouvert, je voudrais partager mon approche ainsi:

À première vue, il ressemble à James Wald est réponse mais a une différence. Vous n'avez pas besoin de diviser vos fichiers de paramètres en quelque sorte dans le sous-projet. Il y a un moyen propre à tout faire dans le super projet si cela est acceptable pour vous. Normalement, vos petits sous-projets ne devraient pas avoir à se préoccuper de la entourant super projets. Ils comprennent leurs sous dépendances et c'est tout. Il doit également être sans importance la façon dont le module répertoire est nommé, en Wald approche le module lui-même a besoin de connaître son nom de répertoire ("B") ici:

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

En revanche, généralement, un super projet connaît ses sous-projets et des répertoires bien, parce qu'ils pourraient être submodules par exemple, qui ont bien défini résoudre les noms qui peuvent être, à partir de la super point de vue du projet, en toute sécurité référencés.

C'est mon installation (à l'aide de Gradle 2.4):

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

Dans le super paramètres du projet.gradle vous pouvez maintenant écrire le code suivant:

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')

Il a toujours l'air assez bavard (et encore n'ajoute pas de véritable hiérarchie comportement), mais conserve l'effort supplémentaire dans le super projet où vous avez normalement besoin de tout savoir à propos de votre contenait des modules, de toute façon.

Le reste est assez simple de nouveau.

Si vous voulez voir mon approche dans la pratique, lisez la section 5.) de ce post de blog, où j'ai explicitement que cette indépendance entre les modules ou consultez mon projet github sur cross-language benchmarks. Mais sachez, vous ont besoin d'un compilateur natif de la chaîne comme gcc ou Clang pour l'exécuter 😉

Espérons que cette aide!
Cheers
Ben