Liste de liens :
Liste de liens :
Cette page contient les spécifications de développement des mises à jour dans TXM.
Les plugins et mises à jour utiliseront le standard OSGi et principalement les outils d'Eclipse.
Actuellement, la mise à jour d'une nouvelle version de TXM se fait par setup et requiert la réinstallation complète de l'application. L'évolution recherchée est la mise à jour incrémentielle. On part d'une version stable auquel on rajoute des améliorations. Ce principe implique que l'application soit segmentée en différents modules indépendants et interchangeables.
La plate-forme d'Eclipse Helios 4.2 permet de mettre en place un système de mise à jour et d'installation de plugins pour une application RCP. L'utilisateur utilise une interface permettant de mettre à jour son application de manière simple et automatique s'il le souhaite. Une autre lui permet d'installer au choix des plugins complémentaires.
Lorsqu'une mise à jour de l'application ou d'un plugin est disponible, une notification est affichée à l'écran sous la forme d'une info-bulle. L'utilisateur peut l'ouvrir pour avoir plus d'information.
Appliqué à TXM, ce système permettrait de simplifier le travail de l'utilisateur pour chaque nouvelle version. Le développement de nouvelles fonctionnalités est également facilité, cela revient à créer un plugin.
Concernant l'hébergement des plugins, il faut décider de leur emplacement et d'une politique de gestion des contributions.
Le système de versions bêta destinés aux bêta-testeurs doit être conservé.
Tuto update site :
Les 3 premiers nombres de la version sont définis par le développeur, le 4e est généré automatiquement par Eclipse à chaque build. Ce qui fait d'une version qu'elle soit alpha, beta ou stable est son repository.
Les versions bêta et rc (stable) sont annoncées par mail dans txm-users avec un objet “Livraison de …”. Les versions alpha sont annoncées par mail seulement dans txm-users par la nouveauté à tester. Objet “MAJ Alpha …”
Par défaut, quand l'application recherche des mises à jour ou des plugins, le repository stable est le seul consulté.
L'utilisateur peut se déclarer alpha ou beta testeur, les mises à jour se feront alors aussi à l'aide des repositories correspondant.
L'hébergement se fait sur un serveur HTTP (Apache, Tomcat, etc.). il faut créer 8 sous-dossiers pour les cibles suivantes :
Les interfaces de mise à jour et de plugins d'Eclipse sont reprises et simplifiées d'après ce tutoriel. Elles utilisent l'API “p2” d'Eclipse.
Une commande est ajoutée dans la barre de menus “Aide”:
Ajout d'une nouvelle préférence dans la page de préférence “TXM” pour activer ou pas la mise à jour automatique.
Une option “Mode expert” est ajoutée dans les préférences (TXM/Avancé). Elle permet de masquer ou non la page de préférence “Install/Update”. Cette page de préférence permet de régler:
Ticket lié : #715
L'interface de mise à jour d'Eclipse est trop orientée développeur. Le scénario doit être modifié tel que :
Outre le nouveau scénario, il serait bien que :
Le product TXM RCP est base sur la feature org.txm.rcp.feature.
Pour que les mises à jour puissent se faire la org.txm.rcp.feature doit inclure le moins de plugins possibles et inclure des features optionelles.
Pour effectuer les test suivants depuis Eclipse, il faut activer l'option “Support software installation in the launched application” dans la partie “config” du run configuration.
Test de la mise à jour de l'application:
Les lignes préfixées (Dev, D) représentent les tâches effectuées par le développeur. Les lignes préfixiées (Testeurs, T) représentent les tâches effectuées par ceux qui vont effectuer les tests. À chaque fin de tâche, un mail doit être envoyé pour signaler qu'elle est terminée.
Pour ne pas casser son environnement TXM, on pourra utiliser une machine virtuelle : http://sourceforge.net/projects/txm/files/software/TXM%20SDK/0.7.2/VirtualBoxImage-Ubuntu-12.04-TXM_SDK_0.7.2_Linux64.tar.gz/download
NK: le protocole de test dev est concluant sous Linux 64. Il est possible d'installer des plugins et de les mettre à jour ainsi que l'application. Le Protocole de test alpha, beta et stable a été validé :
Recette du ticket #715 : vérification de l'UI simplifiée et plus explicite sur le contenu d'une màj.
T=testeur , D=développeur
Après chaque étape, le testeur ou le développeur envoie un mail à la liste txm-info en réponse au mail précédent indiquant la bonne réalisation de l'étape, ce qui provoque le passage à l'étape suivante du développeur ou du testeur.
Si on a des testeurs ALPHA pour les trois systèmes, on peut se passer de la phase BETA et passer en STABLE directement.
Résultat La procédure s'est bien déroulée, voici les différents retours :
Vérifier que des mises à jour fonctionnent dans les cas suivants :