Configurations globales

La première étape consiste à modifier le fichier de configuration commons-parameters.properties dans [ORI_HOME]/src/ori-oai-quick-install-svn:

Les paramètres à modifier dans ce fichier sont les suivants :

Chemin vers tous les modules

Cette partie a déjà du être modifiée lors du rapatriement des projets source avec ORI-OAI-quick-install.

Paramètres communs aux applications

Paramètres propres aux modules

ORI-OAI-repository

ORI-OAI-harvester

ORI-OAI-indexing

ORI-OAI-vocabulary

ORI-OAI-search

ORI-OAI-workflow

ORI-OAI-md-editor

ORI-OAI-ext

ESUP-ECM

ORI-OAI-nuxeo

Enregistrez le fichier.

Déploiement des modules

Maintenant que toutes les configurations globales au module ont été renseignées, le déploiement peut se faire.

Depuis [ORI_HOME]/src/ori-oai-quick-install-svn tapez :

Cette commande lance la tâche init-config dans tous les modules qui en comportent une. Cette tâche permet de créer une arborescence de dossiers (1 par module) dans le dossier [PATH_CUSTOM_CONFIG] que vous avez désigné.
Contrairement aux précédentes versions, il ne faut plus modifier les fichiers de configuration avancée ou de personnalisation à l'intérieur des sources des modules, mais les recopier au bon endroit dans l'arborescence du dossier [PATH_CUSTOM_CONFIG].
Ainsi, les mises à jour des modules n'affecte pas vos personnalisation. Il est aussi maintenant beaucoup plus simple de sauvegarder vos modifications ou de les synchroniser sur un serveur SVN ou GIT par exemple.

Ensuite :

Cette commande lance la tâche init dans tous les modules qui en comportent une :

• ORI-OAI-workflow : toutes les tables de la base de données SQL sont créées
• ORI-OAI-indexing : toutes les tables de la base de données SQL sont créées et le dossier contenant l'index est créé. Si celui-ci existe déjà, il est écrasé
• ORI-OAI-search : le dossier contenant les vignettes est créé. Si celui-ci existe déjà, il est écrasé
• ORI-OAI-harvester : toutes les tables de la base de données SQL sont créées

Attention : Si vous faites une mise à jour depuis une précédente version, vous devez lancer la tâche suivante à la place de la tâche init :

Cette commande lance la tâche upgrade dans tous les modules qui en comportent une :

• Depuis la version 1.0
  • ORI-OAI-harvester : la base de données eXist est transférée vers la base SQL
  • ORI-OAI-vocabulary : si vous aviez défini des vocabulaires statiques dans la version 1.0, ils sont transformés automatiquement dans le nouveau format VDEX utilisé à partir de la 1.1
  • ORI-OAI-workflow : la base de données eXist est transférée vers la base SQL
• Depuis la version 1.1
  • ORI-OAI-harvester : le format de la base de données SQL est migré vers le format de la version 1.4
  • ORI-OAI-workflow : le format de la base de données SQL est migré vers le format de la version 1.4
• Depuis la version 1.4
  • ORI-OAI-harvester : le format de la base de données SQL est migré vers le format de la version 1.5
  • ORI-OAI-workflow : le format de la base de données SQL est migré vers le format de la version 1.5
• Depuis la version 1.5
  • ORI-OAI-harvester : le format de la base de données SQL est migré vers le format de la version 1.6 et les récoltes sont supprimées
  • ORI-OAI-workflow : le format de la base de données SQL est migré vers le format de la version 1.5
• Depuis la version 1.6
  • ORI-OAI-harvester : la version de l'application est mise à jour dans la base de données SQL
  • ORI-OAI-workflow : le format de la base de données SQL est migré vers le format de la version 1.7
• Depuis la version 1.7
  • ORI-OAI-harvester : la version de l'application est mise à jour dans la base de données SQL
  • ORI-OAI-workflow : le format de la base de données SQL est migré vers le format de la version 2.0

Lance le déploiement de tous les modules vers les Tomcat associés en appelant toutes les tâches all.

Remarque : Pour les modules liés au stockage, esup-ecm et nuxeo, l'utilisateur qui installe doit avoir les droits d'accès au répertoire /opt/openoffice.org2.4.

Enfin, pour pouvoir utiliser l'outil de stockage, créer un utilisateur jboss et attribuer lui les droits d'exécution du répertoire [ORI_HOME]/esup-ecm.

Si tous les déploiements se sont bien passés, vous pouvez maintenant démarrer les serveurs Tomcat et passer à la phase de test.