...
Le but est d'étudier les possibilités de migrations de données des versions précédentes de portail.
Il est clair qu'il faut regarder la migration de données des Version Versions 3.x vers 4 par contre les versions 2.x ne seront étudiées qu'en second temps voir voire pas étudiéeétudiées.
Il faudra s'attarder sur la migration des éléments suivants :
- Fragment layout
- Profils utilisateurutilisateurs
- Définition de canaux
Des outils fournis par le JA-SIG sont disponible en version 4, il faudra étudier leur pertinence, leurs limitations et les documenter
Packaging
L'occasion va être donné donnée de refondre complétement le packaging esup car celui n'est plus adapté aux technologies actuelles.
...
Le choix de la gestion de versionning s'oriente fortement vers GIT (il faut prendre contact avec le support SourceSup support-sourcesup@support.renater.fr car il semble qu'on ne peut pas avoir un projet SourceSup qui fait du SVN et du GIT).
Git est déjà utiliser par le JA-SIG.
Le fait de faire ce changement va nous permettre d'incorporer nos modifications/personnalisation personnalisations directement dans le code JA-SIG (disparition des dossiers update/custom) et via des commande GIT de retrouver ce que nous avons modifié par rapport au JA-SIG, et l'exploitant retrouvera ce qu'il a modifié par rapport à ESUP et au JA-SIG.
...
Actuellement le package eSup essaye de faire le grand écart, car il conserve un grand nombre d'options (authentification ldap ou pas, utilisation de cas CAS ou pas, ...). Il faut faire des choix par défaut pour simplifier le package et documenter le changement des comportements ayant disparu.
L'idée d'utiliser des variable variables d'environnement de la JVM a été pressentit pressenti pour faire un partie de la configuration du portail. Cela apporte l'avantage de se faire au runtime et de ne pas etre être obligé de passer par une phase de « init »
Exemple
export JAVA_OPTS="$JAVA_OPTS -Dnancy2.syslog.host=syslog.univ-nancy2.fr"
export JAVA_OPTS="$JAVA_OPTS -Dnancy2.syslog.facility=LOCAL5"
export JAVA_OPTS="$JAVA_OPTS -Dnancy2.syslog.facility.stats=LOCAL6"
NB : Vincent Repain Pour info, le package uPortal 4 de base utilise maintenant des filtres
maven (https://wiki.jasig.org/pages/viewpage.action?pageId=42696767)
...
On va gérer un seul package celui de prod qui ne contiendra donc que les sources du portail.
On générera ensuite un « livrable » quickstart depuis le package de prod (prod + tomcat + portlet AJ-SIG + portlet ESUP + CAS), il faudra surement se reprocher rapprocher du JA-SIG pour savoir comment il génère leur package de quickstart (et s'en inspirer fortement). Le quickstart au final ne devrait nécessiter qu'une JVM préinstallé préinstallée et devrait pouvoir fonctionner en moins de 15min.
...
news, esup-lecture, filemanger, annuaire, imap, helpdesk, web-proxy-portet configuré, esco-grouper (en servlet), portlet calendar,...
On sent bien que pour intégrer ces portlets facilement dans le quickstart il faudrait peut etre être un prérequis : disponibilité en maven
Peut être ne pas aller trop loin, on ne peut integrer intégrer que si ce qui n'as a pas d'autre lien que le portail, le LDAP et un une base (pas de apogée, moodle, etc...)
NB: Le besoin de documenter la manière de contribuer au projet est apparu dans la réunion. (cf https://wiki.jasig.org/display/UPC/Contributing)
C S'est posé posée la question de développé déveloper une interface graphique pour générer la configuration du package (build.properties et config.properties actuellement), on a décidé que ça ne valait pas le coup.
...
La nouvelle version du portail amène une couche mobile plus évoluéévoluée.
Le portail dispose maintenant d'une vue mobile adaptée (donc avec un simple navigateur web mobile) mais aussi de la possibilité d'utiliser une application cliente sur les périphériques mobile.
Le principe de fonctionnement de cette seconde est le suivant :
- On installe une application native mobile (compiler compilée selon la plateforme IOS / Android)
- Cette application native va discuter -entre autre...- avec le portail en JSON (Url/<Context>/layout.json) et CAS/Shibboleth
L'intérêt de l'application dédié dédiée par rapport a la vue mobile via un navigateur a été soulevé soulevée sans remporter un franc consensus. (Christian C : ça remonte à Alain Mayeur pour validation.)
On voit sur cette partie, comme cela l'a été évoqué en groupe esup-mobile, qu'un travail doit être mené sur le serveur CAS afin d'éviter la réauthentification ré-authentification trop fréquente des clients mobiles
Les points a traité traiter dans cette partie :
- Evaluation Évaluation de uMobile
- Possibilité de personnalisation
- Modalité de déploiement des applications dédié dédiés mobile dans AppleStore et AndroidMarket
- Développement dans ce cadre (portlet) - en utilisant la uMobile Portlet Archetype mais aussi esup-commons
- Développement de Native Module, Native Webview Module dans l'appli application native
Adaptation des XSL
(Non traité dans la journée)
Nous disposons déjà sur le site eSup-Portail de « HOW-TO » référençant des modifications de comportement du portail qui ont un impact sur les XSL (exemple : afficher un seul canal à la fois par onglet, ajout de bouton d'ouverture d'iframe, etc...).
Je pense intéressant de refaire le tour de ces modifications de voir si certaines ne seraient pas directement intégrable intégrables dans le portail (de manière optionnelles).
| Ancre | ||||
|---|---|---|---|---|
|
...
Le portail va inclure, grâce à l'utilisation de portlet V2, un moteur de recherche transversal. Celui-ci sera capable de lancer une recherche dans chaque portlet et se ce sont le porltet les portlets elles même mêmes qui renverront les résultats. Il faudrait étudier ces pistes pour les exposer dans le cadre esup-commons.
Sur le même principe le portail V4 va mettre a à disposition un mécanisme de notification qu'il serait intéressant d'étudier pour en faire un retour aux développeurdéveloppeurs.
- aborder les canaux qui ne fonctionneront pas en V4 (tout ce qui n'est pas portlet : anciens canaux de type iChannel) :
...
On voit l'obligation de trouver des prestataires extérieurs capable d'accompagné accompagner les établissements dans leur installation/déploiement. eSup n'a pas les forces nécessaire pour suivre ces demandes.
Il faudra être capable d'identifié identifier des prestataire capable capables de répondre dans ce cadre, l'idéal serait d'arriver a établir des prestation type et peut être un une négociation de tarif.
Infrastructure
...
A l'occasion de la réalisation de ce nouveau package, il serait intéressant de consacrer du temps à la réalisation de documentation sur des préconisations en termes terme d'infrastructure lié liées à l'ENT. Celles-ci pourraient recouvrir :
- infrastructure matérielle (nombre de serveurserveurs, taillage)
- de préconisation logicielle
- montrer des solutions de load balancing
- réplication en ferme de serveur
- métrologie / surveillance
...