web-dev-qa-db-fra.com

Comment importer un script Gradle dans un autre?

J'ai un script gradle complexe qui encapsule une charge de fonctionnalités autour de la construction et du déploiement d'un certain nombre de projets netbeans dans un certain nombre d'environnements.

Le script fonctionne très bien, mais essentiellement, il est tout configuré via une demi-douzaine de cartes contenant des informations sur le projet et l'environnement.

Je veux résumer les tâches dans un autre fichier, afin de pouvoir simplement définir mes cartes dans un simple fichier de construction et importer les tâches de l'autre fichier. De cette façon, je peux utiliser les mêmes tâches principales pour un certain nombre de projets et configurer ces projets avec un simple ensemble de cartes.

Quelqu'un peut-il me dire comment importer un fichier Gradle dans un autre, d'une manière similaire à la tâche de Ant? J'ai parcouru les documents de Gradle en vain jusqu'à présent.

Informations supplémentaires

Après la réponse de Tom ci-dessous, j'ai pensé essayer de clarifier exactement ce que je veux dire.

Fondamentalement, j'ai un script gradle qui exécute un certain nombre de sous-projets. Cependant, les sous-projets sont tous des projets Netbeans, et viennent avec leurs propres scripts de construction de fourmis, j'ai donc des tâches en gradle pour appeler chacun d'eux.

Mon problème est que j'ai une configuration en haut du fichier, telle que:

projects = [
    [name:"MySubproject1", shortname: "sub1", env:"mainEnv", cvs_module="mod1"],
    [name:"MySubproject2", shortname: "sub2", env:"altEnv", cvs_module="mod2"]
]

Je génère ensuite des tâches telles que:

projects.each({
    task "checkout_$it.shortname" << {
         // Code to for example check module out from cvs using config from 'it'.
    }
})

J'ai plusieurs de ces sortes d'extraits de génération de tâches, et tous sont génériques - ils dépendent entièrement de la configuration dans la liste des projets.

Donc, ce que je veux, c'est un moyen de mettre cela dans un script séparé et de l'importer de la manière suivante:

projects = [
    [name:"MySubproject1", shortname: "sub1", env:"mainEnv", cvs_module="mod1"],
    [name:"MySubproject2", shortname: "sub2", env:"altEnv", cvs_module="mod2"]
]

import("tasks.gradle") // This will import and run the script so that all tasks are generated for the projects given above.

Ainsi, dans cet exemple, tasks.gradle contiendra tout le code de génération de tâches générique et sera exécuté pour les projets définis dans le fichier build.gradle principal. De cette façon, tasks.gradle est un fichier qui peut être utilisé par tous les grands projets qui se composent d'un certain nombre de sous-projets avec des fichiers de génération ant Netbeans.

javaantgroovybuildgradle
87
Anthony Roy

La réponse à la question s'est avérée être dans le système de plugins, où vous pouvez ajouter la fonctionnalité souhaitée dans un ensemble de plugins qui peuvent être des fichiers groovy situés dans le répertoire buildSrc/src/main/groovy. Les plugins peuvent également être regroupés sous forme de Jar, même si je n'ai pas essayé cela.

Détails ici: Plugins personnalisés

13
Anthony Roy

Il y a une nouvelle fonctionnalité dans 0.9. Vous pouvez utiliser apply from: 'other.gradle' commande.

Lisez ma question sur la même chose à: Existe-t-il un moyen de diviser/factoriser les parties communes de la construction Gradle

115
Andrey Adamovich

Eh bien, il est difficile de dire ce qui vous sert le mieux sans réellement voir votre fichier de construction.

Je pourrais supposer que la configuration de votre environnement en tant que construction multi-projets devrait vous fournir l'abstraction que vous recherchez.

Dans la racine de votre projet build.gradle vous définissez tous les éléments spécifiques à votre domaine ainsi que les éléments qui s'appliquent à tous vos sous-projets:

repositories {
    add(new org.Apache.ivy.plugins.resolver.FileSystemResolver()) {
        name = 'destRepo'
        addIvyPattern( file( project.properties['repo.dest.dir']).absolutePath + '/[organisation]/[module]/ivys/ivy(-[revision]).xml')
        addArtifactPattern( file( project.properties['repo.dest.dir']).absolutePath + '/[organisation]/[module]/[type]s/[artifact](-[revision]).[ext]')
        descriptor = 'optional'
        checkmodified = true
    }
    ...
}
...
subprojects {
    sourceCompatibility = 1.5
    targetCompatibility = 1.5
    group = 'my.group'
    version = '1.0'
    uploadArchives {
        uploadDescriptor = true
        repositories {
            add rootProject.repositories.destRepo
        }
    }
    apply{ type my.group.gradle.api.plugins.MyPlugin }
    ...
}

dependsOnChildren()

Le répertoire racine du projet peut également contenir un gradle.properties fichier dans lequel vous définissez les propriétés utilisées par vos projets:

buildDirName=staging
repo.dest.dir=/var/repo
...

Puis dans un fichier supplémentaire de la racine de votre projet nommé settings.gradle vous pointez en fait vos sous-projets:

include 'my-first-component',
        'my-second-component'
...
project(':my-first-component').projectDir = new File(rootDir, 'path/to/first/component')
project(':my-second-component').projectDir = new File(rootDir, 'path/to/second/component')
...

Chaque répertoire de sous-projet contient un build.gradle fichier contenant uniquement les éléments spécifiques au sous-projet.

Peu importe si vous appelez gradle depuis le répertoire racine ou sous-projet de votre projet, gradle considérera automatiquement toutes vos définitions effectuées dans les différents fichiers.

Notez également qu'aucune tâche de compilation ne sera exécutée pour la racine de votre projet tant que vous ne chargez aucun plugin au-delà du plugin par défaut au niveau racine.

4
Tom