114 votes

Comment importer un script Gradle dans un autre ?

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

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

Je veux isoler les tâches dans un autre fichier, de sorte que je puisse 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 de base 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 la documentation de Gradle sans succès jusqu'à présent.

Informations complémentaires

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

En gros, j'ai un gradle script 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 ant, donc j'ai des tâches dans gradle pour appeler chacun d'eux.

Mon problème est que j'ai une certaine 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 de nombreux snippets de génération de tâches de ce type, et tous sont génériques - ils dépendent entièrement de la configuration de 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ériques 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 consistent en un certain nombre de sous-projets avec des fichiers de construction Netbeans ant.

148voto

Andrey Adamovich Points 9404

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

Lisez ma question sur la même chose à : http://stackoverflow.com/questions/2566685/is-there-a-way-to-split-factor-out-common-parts-of-gradle-build

17voto

Anthony Roy Points 605

La réponse à la question s'est avérée être dans le système de plugins, où vous pouvez ajouter la fonctionnalité désiré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, mais je n'ai pas essayé.

Les détails ici : Plugins personnalisés

5voto

Tom Points 376

Eh bien, il est difficile de dire ce qui vous convient le mieux sans voir votre fichier de construction.

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

Dans votre projet Root 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 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 votre projet Root nommé settings.gradle vous pointez réellement vers 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 contenant uniquement les éléments spécifiques au sous-projet.

Peu importe si vous invoquez gradle à partir du répertoire racine de votre projet ou de votre sous-projet, gradle prendra automatiquement en compte toutes vos définitions faites dans les différents fichiers.

Notez également qu'aucune tâche de compilation ne sera exécutée pour votre projet Root tant que vous ne chargez pas de plugin autre que le plugin par défaut au niveau Root.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X