Migration technique 4.4 vers 4.5


Ce guide traite de la migration technique de votre application Ametys CMS d'une version 4.4.x à 4.5.0.
Reportez-vous également au guide de migration graphique.

  1. Tableau de compatibilité des plugins
  2. Migrations assistées
  3. Migrations manuelles
    1. Solr et données indexées
    2. Authentification CAS et Kerberos
    3. Workflows
      1. Fichiers de définition des workflows
      2. Plugin workflows
    4. Sources JAVA
      1. API des Expressions (JCR)
      2. Variable LIVE_LABEL
      3. Événement de dé-publication
  4. Plugins
    1. Plugin ClassifiedAds
    2. Plugin Flipbook
    3. Plugin Multimedia
    4. Plugin Proxied Content

Tableau de compatibilité des plugins

Reportez-vous au tableau de compatibilité des plugins et incrémentez les versions de vos plugins (prendre pour chaque plugin la version la plus récente compatible 4.5)

Migrations assistées

La migration technique est maintenant assistée par un script.

Le script effectuera certaines tâches simples automatiquement et signalera les migrations manuelles nécessaires.

  1. Téléchargez le script Télécharger le fichier «migrate-code-helper-4.5-v006.ant» (16 Ko)
  2. Déplacez le fichier à la racine du projet contenant le code à migrer
  3. Exécuter le script ant (avec la tâche par défaut "migration")

En orange apparaissent les opérations faites automatiquement.

En rouge apparaissent les opérations à faire manuellement.

Une fois ces migrations assistées terminées, vous pouvez faire les autres migrations manuelles qui suit.

Migrations manuelles

Solr et données indexées

Le serveur Solr doit être réinstallé. 
Télécharger la version 4.5 http://releases.ametys.org/release/org.ametys/solr-app/4.5.x/4.5.0/zips/

Vérifier que le fichier setenv-solr.sh positionne Java 11 dans SOLR_JAVA_HOME (ou la jvm par défaut qui serait java11)

Après redémarrage du serveur Solr puis Ametys, lancez une indexation totale.

Authentification CAS et Kerberos

Les authentifications CAS et Kerberos ont été déplacées vers un nouveau plugin extra-user-management.

Si votre projet utilise CAS ou Kerberos:

  • ajoutez la dépendance au plugin "extra-user-management" dans le fichier ivy.xml de votre application CMS
  • ajoutez la dépendance au plugin "extra-user-management-site" dans le fichier ivy.xml de votre application site

La configuration est migrée automatiquement vers le nouveau plugin au redémarrage suivant.

Workflows

Fichiers de définition des workflows

Tout d'abord, le fichier WEB-INF/param/workflows.xml n'est définitivement plus supporté. Vous devez déplacer tous vos fichiers de workflow dans le dossier WEB-INF/param/workflows et leur nom doit être celui du workflow suivi du suffixe du type de fichier .xml. Supprimez le fichier  WEB-INF/param/workflows.xml si présent.

Les fichiers de définition des workflows noyau sont maintenant inclus dans les jar.

Si votre projet ne possède aucune surcharge des workflows, la migration revient simplement à supprimer le dossier WEB-INF/param/workflows.

Il faut donc d'abord s'assurer que vos workflows n'ont aucune surcharge projet.

Tout d'accord, supprimez du répertoires WEB-INF/param/workflows les fichiers calendar-simple.xml, editionfo.xml, thesaurus.xml et contentio.xml qui ne sont plus utilisés.
Supprimer également le fichier calendar-default.xml (ce dernier n'a pas été supprimé, il est inclus dans le plugin workspaces mais les surcharges projets ne seraient pas supportées).

Ensuite il va falloir comparer vos fichiers restants avec ceux de la dernière version de template que vous avez livré (ex: si vous étiez en 4.4.10 comparez vos fichiers de workflow avec le template 4.4.10, si vous étiez en 4.5 M4, comparez vos fichiers de workflow avec le template 4.5M4).

Les fichiers concernés sont (dans l'ordre l'alphabétique): blog.xml, bpm-default.xml, calendar-default.xml, container.xml, content.xml, course.xml, courselist.xml, course-part.xml, extraction-description.xml, form-default.xml, job-application.xml, newsletter.xml, orgunit.xml, person.xml, program.xml, udorgunit.xml, ugc-classified-ads-prevalidation.xml, ugc-classified-ads-postvalidation.xml, user.xml, reference-table.xml, subprogram.xml, wall-content.xml, workspaces-content.xml

Si un fichier ne fait pas partie de cette liste, c'est qu'il s'agit d'un workflow spécifique projet, conservez-le.

Si le fichier présente des surcharges projet, conservez-les et appliquez les migrations nécessaires détaillées ici.

Sinon, supprimez le fichier. Vous utiliserez alors la version du noyau et profiterez des corrections/améliorations sans future migration.

Si à la fin votre dossier WEB-INF/param/workflows est vide, supprimez-le.

Plugin workflows

Les plugins default-form-workflow, default-odf-workflow, default-workflow et default-bpm-workflow ont été supprimés des templates.

Les boutons, composants, clé i18n, ressources de ces plugins sont maintenant inclus dans les jars.

Comparer vos plugins default-*** avec ceux de la dernière version de template que vous avez livré (ex: si vous étiez en 4.4.10 comparez vos plugins avec le template 4.4.10, si vous étiez en 4.5 M4, comparez vos plugins avec le template 4.5M4).

Si le plugin.xml est identique (et que le plugin ne comprend pas de source JAVA), supprimez le dossier du plugin.

Si le plugin.xml comporte des différences, supprimez d'accord tous les composants ou extensions identiques à la version noyau. Conservez uniquement les spécificités projets.

Analysez ensuite vos spécificités:

  • s'il s'agit de la déclaration d'un composant/bouton/menu spécifique à votre application, conservez-le tel quel
  • s'il s'agit d'une modification sur la déclaration d'un bouton/menu/composant noyau, vous devrez désactiver le bouton/menu/composant noyau pour utiliser le votre.

 

Sources JAVA

Vous n'êtes concerné par les migrations que si votre projet présente des erreurs de compilation

API des Expressions (JCR)

Certains constructeurs des classes MetadataExpression, StringExpression, BooleanExpression, DateExpression, DoubleExpression, LongEpression et MultilingualStringExpression prenaient des booléens en paramètre pour les données non versionnées et/ou insensibles à la casse. Ces booléens sont remplacés par un ExpressionContext

Par exemple, dans la ligne suivante :

new StringExpression("meta", Operator.EQ, "NiCe'VaLuE", false, true)

le premier booléen concerne le côté non versionné, le second l'insensibilité à la casse. Cette ligne peut donc être remplacée par :

new StringExpression("meta", Operator.EQ, "NiCe'VaLuE", ExpressionContext.newInstance().withUnversioned(false).withCaseInsensitive(true))

ou par :

new StringExpression("meta", Operator.EQ, "NiCe'VaLuE", ExpressionContext.newInstance().withCaseInsensitive(true))

puisque le booléen pour le unversioned est à false par défaut. Le booléen concernant la sensibilité à la casse est également à false par défaut

Variable LIVE_LABEL

La variable LIVE_LABEL a été déplacée dans le CMS.

WebConstants.LIVE_LABEL devient CmsConstants.LIVE_LABEL

Événement de dé-publication

org.ametys.web.ObservationConstants.EVENT_CONTENT_UNPUBLISHED est remplacé par org.ametys.cms.ObservationConstants.EVENT_CONTENT_UNTAG_LIVE

Plugins

Suivant les plugins Ametys que vous utilisez, vous devez suivre les migrations graphiques propres à chaque plugin :

Plugin ClassifiedAds

Lisez le manuel de migration technique à propos de l'ajout du prix dans la modèle des petites annonces.

Plugin Flipbook

Lisez le manuel de migration technique à propos de l'ajout d'un nouveau type de contenu.

Plugin Multimedia

Lisez le manuel de migration technique à propos de l'ajout de nouveaux types de contenus

Plugin Proxied Content

Si le plugin "proxied-content" est utilisé, il vous faut rajouter la dépendance au plugin "proxied-content-site" dans le fichier ivy.xml du site.

Retour en haut