Toolbox

Ce document décrit les tâches ant utilisées dans le processus de compilation de l'ERP Openbravo. Il explique ce pour quoi les tâches ant sont utilisées et quelles propriétés peuvent être utilisées pour contrôler leur comportement. Noter que ant est sensible à la casse (case sensitive).

Principales Taches de Compilation

Cette section explique les principales tâches de compilation en suivant les étapes, comme illustré sur l'image.

Dans la plupart des cas, seules 3 tâches sont nécessaires (install.source, smartbuild et export.database). Plusieurs autres tâches peuvent être utilisées mais elles ne sont pas requises pour le processus standard. Elles sont expliquées dans la section Détail sur les Taches de compilation.

La tâche essentielle pour le processus standard est smartbuild qui effectue tous les processus requis comme expliqué ci-dessous. Cette tâche possède deux propriétés facultatives :

local pour les développements locaux ou distants, qui est par défaut initialisé à yes.
restart indique si après le processus de compilation, tomcat doit être redémarré (avec no comme valeur par défaut).

La différence entre le développement local et distant est illustré dans le diagramme sur la droite. Le développement local consiste en des modifications effectuées par le développeur lui-même. Le développement distant consiste en des modifications effectuées par d'autres développeurs. Les modifications issues du développement distant sont tirées depuis le système source contenant le code révisé.

Installation initiale

Après avoir téléchargé les fichiers source Openbravo ERP (par exemple depuis Mercurial) il est nécessaire de l'installer et de le déployer.

La première étape consiste à configurer proprement toutes les propriétés requises. Les propriétés sont stockées dans le fichier Openbravo.properties. Ce fichier n'est pas dnas le source de base, mais il peut facilement être généré depuis le Openbravo.properties.template. Une autre façon de le paramétrer de manière graphique est d'exécuter l'outil de paramétrage pour la plateforme courante qui est localisé dans le dossier config (lancer ant setup en premier).

Une fois les propriétés configurées, l'étape suivante est de construire l'application depuis zéro et de la déployer. Tout ceci est fait par la tâche install.source. Cette tâche crée la base de données, insère les données exemple, et compile et déploie l'application en accord avec le mode de déploiement choisi. Pour l'exécuter, il suffit de taper dans le dossier racine d'Openbravo ERP :

ant install.source

Lorsque Openbravo ERP est installé et tourne, on peut passer au développement. En général les nouveaux développements devraient être fait par l'intermédiaire de modules, de plus amples explications sur comment développer les modules peuvent être trouvées dans le Modularity article.

Compilation

Une fois les développements prêts à être testés ,il nécessaire de compiler l'application. Il n'est pas nécessaire de faire une compilation complète, mais des compilations incrémentales, ce qui consiste à créer uniquement ce qui a été modifié. Ceci se fait par la commande smartbuild :

ant smartbuild

Cette tâche génère et compile les sources pour les éléments modifiés et en fonction du mode de déploiement, il les déploie aussi. Il est possible de redémarrer Tomcat à partir de cette même tâche en positionnant la propriété restart à yes:

ant smartbuild -Dlocal=yes -Drestart=yes # note the -Drestart=yes

Export de la base de données - Export Database

Dans la plupart des cas, les développements incluent des modifications dans la base de données. Ces modifications peuvent être conservées dans les fichiers xml en utilisant l'outil DBSourceManager. DBSourceManager exporte vers les fichiers xml files uniquement les modules (y compris le core) qui sont dans l'état En Development. Pour exporter la base de données, exécuter :

ant export.database

Après cette étape les fichiers xml du modèle peuvent être poussés/validés vers le système de révision du code source, afin que les autres développeurs puissent les récupérer et continuer à travailler sur la dernière version.

Mise à jour de la Base de données - Update Database

Les modifications du modèle de la base de données sont distribuées en validant le schéma de base de données, par exemple de XML vers Mercurial. D'autres développeurs récupérent les modifications depuis Mercurial et peuvent les appliquer pour mettre à jour leur propre base de données. Après avoir mis à jour la base de données, le processus est exactement le même que le processus local, qui est de compiler et déployer les éléments qui ont été modifiés depuis la dernière compilation. Toutes les actions requises (mise à jour de la base de données, compilation des dernières modifications et les déployer) peuvent être faites en une seule commande smartbuild :

ant smartbuild -Dlocal=no # note the -Dlocal=no

La seule différence avec le développement local est dans le paramètre local qui force le processus à mettre à jour la base de données dans le cas où les fichiers xml ont été changés.

Validation de la base de données - Validate Database

Quand un module est exporté en utilisant la tâche export.database, il est d'abord validé en contrôlant les erreurs les plus communes. Si la validation échoue alors la tâche export.database échouera aussi et l'export ne sera pas possible.

Les contrôles suivant sont faits :

Une table définie dans le Dictionnaire Applicatif doit être présente dans la base de données et vice versa.
Les définitions de colonne dans la base de données et dans le Dictionnaire Applicatif sont comparées, toute différence est rapportée. Le type de donnée de la colonne, la valeur par défaut et la longueur sont vérifiés.
Les tables doivent avoir une clé primaire.
La clé étrangère doit faire partie d'une contrainte de clé étrangère.
La longueur des noms de table, de colonnes et de contraintes sont vérifiés (Oracle a une limitation à 30 caractères).

Vous pouvez aussi exécuter la tâche de validation de base de données (validate database) avec cette commande :

ant validate.database

Cela controlera la totalité de la base de données et le modèle. Noter que lorsque la validation de la base de données est faite, en tant que partie de la tâche export.database alors seules les tables et colonnes des modules exportés sont controlées.

Validation du Module - Validate module

Quand un module est packagé avec la tâche ant package.module, il est d'abord contrôlé pour les erreurs les plus communes. Si une erreur est détectée alors la tâche de package.module échouera.

Plus particulièrement les vérifications suivantes sont faites :

Un module doit dépendre du Core, ou dépendre d'un module qui dépent du Core (récursivement).
Le chemin dans le dossier modules/.../src doit correspondre au package java défini pour le module.
Les packages java des Packages de données qui font partie des modules doivent être en ligne avec le package Java défini pour le module. Donc si le module a le package Java org.example, alors tous les packages de données doivent avoir un package Java qui commence par org.example.
Le type et le texte de la license doivent être définis.
Si le module est un Industry Template alors il doit dépendre du core et la dépendance doit être définie à 'Inclus'.
Si le module utilise des objets de l'UI tels qu'une fenêtre ou un onglet, alors son champs 'traduction requise' doit être positionné à yes.

La validation du module peut être exécutée séparément à travers cette tâche ant :

ant validate.modules -Dmodule=${javapackageofmodule}

où ${javapackageofmodule} est le package Java du module.

Tâches de Test Ant

Openbravo utilise certaines tâches ant pour exécuter des tests Junit.La principale est run.tests:

ant run.tests

Cela exécutera les tests qui sont sans effets de bord. Les tâches de test ant supposent que les sociétés Small Bazaar and Accounting Test ont été installées.

Détail sur les Taches de compilation

Cette section contient une liste détaillée de toutes les tâches de compilation valides.

Bibliothèques de tâches de compilation

Tâche	Description	Remarques	Sous Tâches
core.lib	Compile et génère un fichier .jar depuis le projet src-core, qui est requis par la wad.lib et au reste des tâches de compilation.	Requis par: wad.lib
wad.lib	Compile et génère un fichier .jar depuis le projet src-wad qui est requis par les tâches de compilation. Ce projet contient le WAD , le générateur automatique de fenêtres.	Requiert: core.lib, database created Requis par: compile.*	eclipse.wad.lib
trl.lib	Compile et génère un fichier .jar depuis le projet src-trl qui est requis par les tâches de traduction. Ce projet permet de traduire dans différentes langues les fenêtres manuelles.	Requiert: core.lib	eclipse.trl.lib

Tâches de compilation

Tâche	Description	Remarques	Sous Tâches
smartbuild	Fait une compilation incrémentielle de l'application. Inclut: update.database compile deploy Toutes ces tâches sont faites uniquement si nécessaires.	Requiert: La base de données doit être créée et renseignée par des données. Propriétés: local: (par défaut à yes) quand cette propriété est positionnée à no, la tâche update.database est exécutée, sinon elle ne l'est pas. restart: (par défaut à no) si positionné à yes, tomcat est redémarré aprés le processus de compilation. tr: (par défaut à yes) si positionné à no, le processus de traduction n'est pas exécuté.
generate.entities	Génère les fichiers Java pour le dossier src-gen, et les compile. Ils sont utilisés par la DAL (Data Layout Access) pour accèder aux informations de la base de données.	Requiert: La base de données doit être créée et renseignée avec des données.
install.source	Installe l'application complète: crée la base de données, la compile et génère un fichier war prêt à être déployé ou copie les classes au dossier de Tomcat (dépend de la valeur de la propriété deploy.mode dans Openbravo.properties).	Appelle: create.database, core.lib, wad.lib, trl.lib, compile.complete.deploy, applyModule	eclipse.install.source: Cela fait la même chose et appelle en plus les tâches eclipse.* correspondantes, mais ne génère pas le fichier war.
compile	Génère les classes Java pour les fenêtres du WAD, génère les classes Java depuis les fichiers xsql modifiés, compile toutes les classes modifiées (incluant celles générées), fait des insertions dans les tables de traduction pour les entrées inexistantes des fichiers de l'interface utilisateur et copie la totalité dans le dossier WebContent.	Requiert: wad.lib, trl.lib, la base de données créée et renseignée. Appelle: translate Propriétés: tab: spécifie le nom de la fenêtre qui doit être générée, pour spécifier plus d'une fenêtre ajouter les comme une liste séparée par des virgules. tr: Si positionné à "no" le processus de traduction ne sera pas appelé. module: Une liste (séparé par des virgules) de modules de packages Java pour générer les seules fenêtres contenant des objets pour ces modules.	compile.src: Cela fait la même chose que compile mais sans générer les fenêtres du WAD. compile.development: Copie aussi les fichiers dans le contexte Tomcat. eclipse.compile: Fait la même chose que 'compile' en forçant Eclipse à créer les fichiers Java, si appelé depuis Eclipse. Si c'est appelé depuis une ligne de commande, un BUILD FAILED sera affiché à la fin du processus car il essaie de lancer le compilateur Eclipse. compile.complete: Fait la même chose que 'compile', mais il supprime avant tous les fichiers générés et créés, ainsi l'application complète est construite. Notez qu'il ne faut pas utiliser les propriétés des onglets ou des modules car dans ce cas l'application sera reconstruite partiellement. compile.complete.development: la même chose que 'compile.complete' mais après que le processus ait copié toutes les classes générées dans le contexte tomcat. eclipse.compile.complete: la même chose que 'compile.complete' mais en appelant Eclipse pour faire la compilation des classes générées. compile.deploy: La même chose que 'compile' ou 'compile.development', en fonction du paramètrage de la propriété 'deploy.mode' dans le fichier Openbravo.properties. compile.complete.deploy: La même chose que 'compile.complete' ou 'compile.complete.development', en fonction du paramètrage de la propriété 'deploy.mode' dans le fichier Openbravo.properties.
translate	Vérifie dans les fichiers des fenêtres manuelles de l'Interface Utilisateur, les éléments traduisibles qui n'ont pas encore été enregistrés et les enregistre, ceci est nécessaire pour traduire ces interfaces dans différentes langues.	Requiert: trl.lib Appelé par: Cette tâche est appelée par les tâches compile.* dans le cas où la propriété 'tr' n'est pas positionnée à 'no'
war	Génère un fichier war depuis le code compilé existant. En fait, il ne fait que compresser l'application dans un seul fichier war.	Requiert: compile.*: l'application doit être créée avant d'appeler cette tâche.
deploy.context	Déploit le fichier war existant dans le contexte tomcat en utilisant le gestionnaire tomcat.	Requiert: le fichier war doit être créé. Le gestionnaire Tomcat doit fonctionner. Ces propriétés doivent être correctement paramétrées dans le fichier Openbravo.properties : tomcat.manager.url tomcat.manager.username tomcat.manager.password

Tâches Base de Données

Tâche	Description	Remarques	Sous-tâches
update.database	Synchronise la base de données avec les fichiers xml de la base de données en cours. Par défaut, il vérifie qu'aucune modification dans le Dictionnaire Applicatif de la base de données n'ait été faite, si c'est le cas, le processus est arrêté.	Propriétés: module: Une liste de modules javapackages. Cette propriété concerne uniquement la tâche update.database.mod. Si fixé, seule cette liste de modules sera mise à jour. apply.on.create: Si fixé à "true", dans le cas où il y a des modules, elles seront appliquées, sinon elles seront positionnées dans l'état "In process". force: (par défaut : faux) Ne vérifie pas les modifications de base de données et met directement à jour. Cela peut entrainer des pertes de données sur la base de données. onlyIfModified: (par défaut positionné à faux sauf pour le smartbuild) vérifie les fichiers xml et met à jour uniquement si il y a des modifications depuis la dernière synchronisation de la base de données.	update.database.mod: Met à jour uniquement une liste de modules (propriété module requise). update.database.script: C'est la même chose que update.database.structure mais ça ne modifie pas la base de données. Cela génère simplement un fichier de script SQL avec les instructions qui seront exécutées par les autres tâches.
create.database	Creates the database from the xml files, note that the database is first removed. If the apply.on.create property is set, masterdata and sampledata will be inserted in the database. If not, only sourcedata will be inserted.	Properties: apply.on.create: If is set to "true" and there are modules they will be applied, otherwise they will be set as "In process" status.	create.database.script: The same as create.database.structure but does not affect the database it only generates the sql script file with all the statements that would be executed by the other tasks.
export.database	Synchronizes xml files with the database current contents. By default they are only exported in case there are modifications in the database. In addition performs database validations for the modules which are exported.	Properties: force: (default to false) Forces exportation even if there are no changes in the database.

Modules

Task	Description	Notes	Sub Tasks
apply.modules	Applies the installed but not applied modules, that is: it updates the database for them, imports reference data in case they contain it, set them in installed status, compiles the required windows and generates a war file for the application.	Properties: module: A list of module javapackages to apply.
package.module	Validates the module and if no errors are found generates the obx file for the module.	Properties module: Java package for the module to extract. obx.export.RD: If set to true the reference data is exported for the modules (if it has), by default is false. obx.export.DB: If set to true the database is exported for the modules, by default is false. obx.export.CS: If set to true the configuration script is exported (in case there is an active template), by default is false.
package.core	Creates a new obx file with the current source files. To execute this task it is necessary to be in a mercurial workspace.	Properties calculate.core.revision: When this property is true the minor revision is calculated taking into account the local number for the last changeset in the repository (summing 10000 to it). If it is false the version is the one in the xml files. By default it is true.
export.config.script	Generates the configuration script for the current active template (if any). More information about Industry Templates and configuration scripts can be found here	Note: export.database must be executed before running this process

Test Tasks

Task	Description
run.tests	The default, it runs the suite: org.openbravo.test.AntTaskTests. These tests are side effect free and can be run multiple times, after the run the database should be in the same state as before.
run.quick.tests	This task runs test cases which are fast and which test the most important parts of the system. It runs the test suite: org.openbravo.test.AllQuickAntTaskTests.
run.all.tests	Runs the suite org.openbravo.test.AllAntTaskTests. This suite contains all the test cases, also tests which can change the database.

Languages:

Retrieved from "http://wiki.openbravo.com/wiki/ERP_2.50:Developers_Guide/Concepts/Development_Build_Tasks/fr"

This page has been accessed 7,687 times. This page was last modified on 14 June 2011, at 11:03. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.