Liste des tâches Gradle du build Adélia par composants

adelCompoSetInit

Cette tâche initialise le projet de build en créant la structure nécessaire à la fabrication des artéfacts en fonction de la liste des noms de composants Adélia déclarée dans la clé adelLstComponents du fichier gradle.properties.

La figure suivante montre le résultat de la tâche avec les clés adelCompoSetName=sampleApp et adelLstComponents=COMPO_1 COMPO_2.

Les sous-répertoires, ayant des noms de composants Adélia, vont contenir les artéfacts des objets Adélia contenus dans chaque composant.

La figure suivante présente le détail structurel d'un répertoire "composant" (pour cet exemple COMPO_1).

Chaque sous-répertoire "composant" contient un emplacement pour la construction des artéfacts des différents types possibles.

Il se peut qu'un emplacement soit vide s'il n'existe pas, dans le composant Adélia, d'objet correspondant à un type d'artéfact particulier.

adelCompoSetCreateAS400Lib

Cette tâche crée sur l'AS400 déclaré, dans les attributs d'environnement, les bibliothèques nécessaires à la génération des objets Adélia pour la construction des artéfacts de type As400Adelia et As400Server.

Les bibliothèques créées sont celles définies via les clés adelGenAS400.as400Adelia.genLib, adelGenAS400.as400Server.genLib, adelGenAS400.language, adelGenAS400.as400Adelia.jobdLib et adelGenAS400.as400Server.jobdLib du fichier gradle.properties.

adelCompoSetClean

Cette tâche supprime le répertoire du nom de l'application à builder ainsi que les bibliothèques AS400 spécifiées pour la construction des artéfacts de type As400Adelia et As400Server (les noms de bibliothèques sont définies via les clés adelGenAS400.as400Adelia.genLib et adelGenAS400.as400Server.genLib du fichier gradle.properties).

Le projet de build est vidé et il est nécessaire de réexécuter la tâche adelCompoSetInit pour l'initialiser.

adelCompoSetGenerate

Cette tâche lance la génération Adélia des objets appartenant aux domaines définis par la clé adelLstComponents de l'environnement défini par la clé adelEnvName.

Le nombre d'objets à générer dépend du mode de génération (valeur de la clé adelGenIncremental) :

• Tous les objets si le mode est global,

• Uniquement les objets modifiés depuis le dernier build exécuté si le mode est incrémental.

Dans les deux modes, si la génération Adélia d'un objet est en erreur, cela ne bloque pas les générations des autres objets, mais le build est stoppé sur la tâche adelCompoSetGenerate.

Attention : si un objet Adélia généré lors d'un précédent build a été supprimé du référentiel, la tâche  adelCompoSetGenerate ne supprimera pas les objets binaires issus de la précédente génération, et ces binaires feront partie de l'artéfact qui sera construit.

A l'issue du traitement de cette tâche, les fichiers produits par la génération sont placés dans les répertoires suivants :

adelCompoSetBuild

Cette tâche est la tâche principale d'un build Adélia par composants. Elle se scinde en deux phases :

1. Appel de la tâche adelCompoSetGenerate pour exécuter la génération Adélia,

2. Traitement des fichiers produits par la phase 1 pour construire les artéfacts associés.

A l'issue de la phase 2, les artéfacts produits sont placés dans les répertoires suivants :

Pour les artéfacts de nature Java, la compilation des fichiers sources .java (effectuée par la tâche adelCompoSetBuild) s'appuie sur les options de compilation définies dans le fichier adeliws.ini.

En outre, si le paramètre de build adelCreateSourceFilesArtifacts a pour valeur Y, des artéfacts de sources L3G sont produits en plus des artéfacts principaux décrits plus haut :

 En outre, si le paramètre de build adelGenDebugMode a pour valeur Y, des artéfacts de debug sont produits en plus des artéfacts principaux décrits plus haut :

uploadArchives

Cette tâche permet de transférer les artéfacts construits dans le référentiel d'upload.

Il est nécessaire de renseigner la clé uploadArchivesReleaseRepo ou uploadArchivesSnapshotRepo en fonction du type de version des artéfacts.

Cette tâche doit être appelée après la tâche adelCompoSetBuild.

Contrairement au build Adélia par domaines où le group ID de tous les artéfacts produits lors d'un build était identique (fixé via la clé "group" dans le fichier gradle.properties), les artéfacts construits lors d'un build par composants ont un group ID issu du composant auquel ils appartiennent.

↑ Haut de page

Lien entre dépendance de composants et dépendances d'artéfacts produits

Cette section décrit comment se traduit une dépendance logique entre deux composants A et B en dépendances de construction d'artéfacts/POMs produits par l'outil de build Gradle.

Définition d'une dépendance

Au niveau Gradle, une dépendance entre A et B se traduit au niveau des artéfacts produits par une dépendance d'exécution entre artéfacts.

Celle-ci est explicitement décrite dans chaque POM d'artéfact issu de A.

La dépendance entre artéfacts est une dépendance de scope "runtime" sauf pour les cas de dépendances suivantes où elle est de scope "compile" :

• Artéfact Cloud de A dépendant de l'artéfact Pojo de B,
• Artéfact JavaClient de A dépendant de l'artéfact Pojo de B,
• Artéfact Pojo de A dépendant de l'artéfact Pojo de B,
• Artéfact WSRest de A dépendant de l'artéfact Pojo de B,
• Artéfact WSSoapAar de A dépendant de l'artéfact Pojo de B,
• Artéfact WSSoapJar de A dépendant de l'artéfact Pojo de B.

De plus, comme dans le Build Adélia par domaines, il existe une dépendance entre artéfacts issus d'un même composant, à savoir :

• Artéfact Cloud de A dépendant de l'artéfact Pojo de A,
• Artéfact JavaClient de A dépendant de l'artéfact Pojo de A ,
• Artéfact WSRest de A dépendant de l'artéfact Pojo de A,
• Artéfact WSSoapAar de A dépendant de l'artéfact Pojo de A,
• Artéfact WSSoapJar de A dépendant de l'artéfact Pojo de A.

Rappel sur les types d'artéfacts produits :

Dépendance de localisation Client

Description d'une dépendance "Client" du composant A vers le composant B en termes de dépendances d'artéfacts :

Dépendance de localisation Serveur

Description d'une dépendance "Serveur" du composant A vers le composant B en termes de dépendances d'artéfacts :

Dépendance de localisation Client Serveur

Description d'une dépendance "Client Serveur" du composant A vers le composant B en termes de dépendances d'artéfacts :

Dépendance des tâches Gradle du build Adélia

Le tableau ci-après détaille pour chaque tâche du build, les informations en entrée ainsi que les tâches dépendantes.

Lancement d'un build en ligne de commande

Le lancement s'effectue en plusieurs étapes décrites ci-après :

1. Ouvrez une fenêtre de commande DOS exécutée en tant qu'administrateur,

2. Placez-vous dans le répertoire du projet de build,

3. Suivant le mode de génération choisi et la volonté de stocker les artéfacts dans un référentiel, lancez la commande suivante :

(1)  : adelGenIncremental=N

(2)  : adelGenIncremental=Y

Remarques :

• • L'appel à la tâche adelCompoSetClean en mode global permet d'assurer une cohérence entre le contenu d'un artéfact et les objets Adélia générés (cas d'un objet Adélia supprimé entre deux build),

• • Si le mode incrémental est activé et que la tâche  adelCompoSetClean a été exécuté, le prochain build en mode incrémental verra son mode forcé à global,

• • Puisque Gradle offre les mécanismes de dépendance de tâche et de cache d'entrées de tâch, l'appel à la tâche adelCompoSetBuild déclenchera l'exécution de la tâche  adelCompoSetInit (initialisation du projet) dans les cas suivants :

• • • Lors du premier lancement du build Adélia,

• • • Si entre deux exécutions de build, le nom de l'application à builder (paramètre adelCompoSetName) ou la liste des composants Adélia à générer (paramètre adelLstComponents) ont été modifiées.

↑ Haut de page

Lancement d'un build via Jenkins

L'aide se base sur Jenkins version 2.66 et sur le plugin Gradle pour Jenkins version 1.27.1.

Dans une démarche d'intégration continue, l'outil Jenkins permet de lancer et d'ordonner des travaux (jobs) de manière automatique.

Il est possible de définir un job comme étant un build Adélia pour que celui-ci soit exécuté par Jenkins.

Cela peut se faire de deux manières différentes , décrites ci-après.

Build Adélia en ligne de commande

Lors du paramétrage du job, dans la section Build, ajoutez une étape au build via l'option "Exécuter une ligne de commande batch Windows": il est possible de saisir un ensemble de commandes au format batch DOS, qui seront exécutées séquentiellement comme par exemple :

cd /d "D:\build"

call gradlew adelCompoSetClean adelCompoSetBuild uploadArchives

Build Adélia via le plugin Gradle

Lors du paramétrage du job, dans la section Build, ajoutez une étape au build via l'option "Invoke Gradle script" : choisissez le bouton radio "Use Gradle Wrapper" puis renseignez les champs "Wrapper location" (saisissez le chemin du projet ou se trouve le fichier gradlew.bat - dans notre exemple D:\build) et "Task" (saisissez la liste des tâches Gradle à exécuter - dans notre exemple adelCompoSetClean adelCompoSetBuild uploadArchives).

De plus, il faut préciser le répertoire racine du projet de build. Pour cela, cliquez sur le bouton Avancé de l'étape et renseignez le champ "Root Build script" (dans notre exemple D:\build).

↑ Haut de page