Log in / create account
Openbravo.com
Issues
Forge
University
View source | Discuss this page | Page history | Printable version   

ERP 2.50:Developers Guide/Concepts/Development Build Tasks/fr

Languages: 

English  |  Français  |  Italiano | Translate this article...

Contents

Introduction

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

Build-process2.png

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 :

  1. local pour les développements locaux ou distants, qui est par défaut initialisé à yes.
  2. 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 :

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 :

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: 

English | Translate this article...

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

This page has been accessed 7,869 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.