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.
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)
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.
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.
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.
Les authentifications CAS et Kerberos ont été déplacées vers un nouveau plugin extra-user-management.
Si votre projet utilise CAS ou Kerberos:
La configuration est migrée automatiquement vers le nouveau plugin au redémarrage suivant.
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.
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:
Vous n'êtes concerné par les migrations que si votre projet présente des erreurs de compilation
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
La variable LIVE_LABEL a été déplacée dans le CMS.
WebConstants.LIVE_LABEL devient CmsConstants.LIVE_LABEL
org.ametys.web.ObservationConstants.EVENT_CONTENT_UNPUBLISHED est remplacé par org.ametys.cms.ObservationConstants.EVENT_CONTENT_UNTAG_LIVE
Suivant les plugins Ametys que vous utilisez, vous devez suivre les migrations graphiques propres à chaque plugin :
Lisez le manuel de migration technique à propos de l'ajout du prix dans la modèle des petites annonces.
Lisez le manuel de migration technique à propos de l'ajout d'un nouveau type de contenu.
Lisez le manuel de migration technique à propos de l'ajout de nouveaux types de contenus
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.