Technical migration 4.4 to 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. Compatibility table plugins
  2. Assisted migration
  3. Migrations manuelles
    1. Solr and indexed data
    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

Compatibility table 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)

Assisted migration

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

script will perform certain simple tasks automatically, and signal any manual migrations required.

  1. Téléchargez le script Télécharger le fichier «migrate-code-helper-4.5-v006.ant» (16 Ko)
  2. Move the file to the root of the project containing the code to be migrated
  3. Run script ant (with default task "migration")

En orange apparaissent les opérations faites automatiquement.

En rouge apparaissent les opérations à faire manuellement.

Once you've completed these assisted migrations, you can carry out the other manual migrations that follow.

Migrations manuelles

Solr and indexed data

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/

Check that the setenv-solr.sh file sets Java 11 in SOLR_JAVA_HOME (or the default jvm, which would be java11).

After restarting the server Solr then Ametys, run a full indexing operation.

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 and 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 and 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 becomes 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.

Back to top