Outils pour utilisateurs

Outils du site


public:plugins_structure

[Proposition SJ à discuter pour le découpage en plugins des projets]

Objectifs

Découper les projets TBX et RCP en projets/plugins Eclipse RCP afin de faciliter le développement de TXM, l'insertion dans le projet de nouveaux développeurs ainsi que les mises à jour via le système d'update Eclipse RCP. Pour chaque commande il faudra a priori un plugin TBX (computing) et un plugin RCP (UI). Chaque plugin devrait contenir :

  • son propre Store RCP de préférences
  • ses propres chaînes de messages (dans les différentes langues ou non, voir plus bas, fragments)

Ce développement est étroitement lié à l'architecture des préférences TBX et RCP, voir : Architecture des préférences TBX et RCP. Le travail/remaniement risque d'être conséquent et générateur de divers problèmes et bugs, j'aurais tendance à proposer un cycle de développement long pour ces devs (6 mois ?). L'interdiction par la RCP d'avoir des dépendances cycliques entre plugins risque d'engendrer de la modification et de la restructuration du code source en lui-même. Il faudra ensuite notamment revalider toutes les fonctionnalités de TXM.

NOTE: tbx.chartengine.jfreechart embarque des bribes de code relatif à l'UI pour le futur port vers TXM Portal. Mais certaines de ces fonctionnalités ne seront sans doute pas mutualisées entre RCP et Portal, il faudrait revoir cela, je pense notamment à une partie de la gestion des événements/entrées utilisateur (bien qu'une abstraction au niveau TBX pourrait être intéressante pour mutualisation GWT/SWT).

Solution

Proposition de structuration des projets, exemple pour la commande CA

  • org.txm.tbx.ca
  • org.txm.tbx.ca.feature
  • org.txm.rcp.ca
  • org.txm.rcp.ca.feature

Ou bien ajouter un sous package comme actuellement ?

  • org.txm.tbx.functions.ca

Est-ce utile et si oui peut-être que org.txm.tbx.commands.ca serait mieux comme on parle de 'Commands' sur la Forge ?

D'autre part garde-t-on le découpage actuel, ex. org.txm.tbx.stat.engine.r.function.ca, etc. ?

Est-on réellement obligé de créer des projet de features pour chaque plugin ? Notamment pour les plugins non optionnels ? Voir si le système de maj peut fonctionner sans features, cela simplifierait énormément le travail.

Pour les plugins non optionnels et le code source de type 'base' (abstraction, etc.) est-ce qu'il n'y a pas un mécanisme RCP permettant de conserver un seul plugin/projet mais de pouvoir builder le plugin en plusieurs jars afin, lors d'une maj, de ne provoquer le téléchargement que du jar modifié ?

Proposition de structuration des packages, exemple pour la commande CA

TBX

  • org.txm.tbx.ca
    • CA.java
    • chartsengine
      • jfreechart
        • JFCCARenderer.java
      • r
        • RCARenderer.java
    • messages
      • CAMessages.java
      • messages.properties
      • messages_fr.properties
      • messages_ru.properties
    • preferences
      • CAPreferencesStore.java
    • searchengine (inutile pour la CA ?)
      • cqp
    • statsengine
      • r
        • CA.java
        • FactoMineRCA.java
        • ICA.java

RCP

  • org.txm.rcp.ca
    • chartsengine
      • jfreechart
        • listeners
        • etc.
      • r
        • listeners
        • etc.
    • commands
      • ComputeCA.java
    • editors
      • CAFactorialMapChartEditor.java
      • CaEditor.java
      • ColRowInfosLabelProvider.java
      • ColsRowsInfosEditor.java
      • SingularValuesEditor.java
      • inputs
        • CAEditorInput.java
    • export
    • icons
    • import (inexistant pour l'instant pour la CA)
    • links
      • CAToXxxxx.java (inexistant pour l'instant pour la CA)
    • messages
      • CAMessages.java
      • messages.properties
      • messages_fr.properties
      • messages_ru.properties
    • preferences
      • CAPreferencesPage.java
      • CAPreferencesStore.java
    • searchengine (inutile dans les plugins RCP ?)
    • statsengine (inutile dans les plugins RCP ?)

Les bonnes pratiques semblent préconiser de faire un fragment étendant le plugin hôte pour chaque langue (c'est ce que fait la team Eclipse apparemment), cela complexifie la traduction et multiplie les projets Eclipse mais cela a aussi ses avantages non négligeables, voir notamment : Nommage des symboles d'externalisation. Est-ce que les avantages sont suffisants dans le cadre de TXM pour que l'on parte là-dessus malgré la complexification ?

Proposition de nommage des packages

Packages 'root' dans les projets 'root' TBX (org.txm.tbx) et RCP (org.txm.rcp)

Ceci concerne typiquement le code mutualisé entre toutes les implémentations et le code abstrait.

  • org.txm.tbx.base
  • org.txm.rcp.base

Hiérarchie et packages abstraction/implémentations

Ceci concerne typiquement l'ajout à TXM de la possibilité de changer de plugin pour une commande donnée (mode de calcul, technologie, etc.).

Exemple pour CA :

Plugin TBX (abstraction)

  • org.txm.tbx.commands.base.ca
    • ICA.java

Plugin CA FactoMineR (implémentation)

  • org.txm.tbx.commands.factominer.ca
    • FactoMineRCA.java

Plugin CA (implémentation, package R CA)

  • org.txm.tbx.commands.ca.ca
    • CA.java

Choix des moteurs de statistiques et de corpus

Dans l'absolu on pourrait essayer de rétablir l'abstraction des moteurs dans TXM mais là il ne s'agit plus d'un remaniement du code mais d'une refonte très complexe. Cela pourrait donner quelque chose de ce type pour CA :

Plugin TBX (abstraction)

  • org.txm.tbx.commands.base.ca
    • ICA.java

Moteur R

Plugin TBX (abstraction R)

  • org.txm.tbx.commands.statsengine.r.base.ca
    • IRCA.java

Plugin CA FactoMineR (implémentation R)

  • org.txm.tbx.commands.statsengine.r.factominer.ca
    • FactoMineRCA.java

Plugin CA (implémentation, package R CA)

  • org.txm.tbx.commands.statsengine.r.ca.ca
    • CA.java

Moteur Java “light”

Plugin TBX (abstraction si besoin)

  • org.txm.tbx.commands.statsengine.java.base.ca
    • IJavaCA.java

Plugin CA FactoMineR (implémentation Java)

  • org.txm.tbx.commands.statsengine.java.ca
    • JavaCA.java

Méthode

NOTE: avant cela, trouver un moyen de ne plus être obligé d'inclure les .class de la Toolbox complète utilisés par Groovy dans les build, cela double la taille du JAR TBX et de plus ça semble difficilement compatible avec le découpage en plugins.

NOTE: we may need to simplify the management of all the projects of TXM by using a Team Projet Set (TPS) or using Maven, Buckminster, etc. See: http://www.eclipseonetips.com/2010/01/25/checkout-multiple-projects-automatically-into-your-eclipse-workspace/ This will be especially useful/needed when we'll split the layers and commands to separated plug-in projects.

  • découper/regrouper/réfactorer les commandes TBX et RCP dans des packages par commande, ex. org.txm.tbx.ca, org.txm.rcp.concordance, etc.
    • en profiter pour renommer les projets de base org.txm.tbx et org.txm.rcp
  • dispatcher/décentraliser toutes les chaînes des fichiers messages.properties, messages_fr.properties, etc. dans des sous packages du type org.txm.tbx.ca.messages
  • implémenter un système de Store RCP pour la TBX
  • dispatcher/décentraliser toutes les préférences de la TBX et de la RCP dans des sous packages du type org.txm.tbx.ca.preferences
    • en profiter pour déplacer et renommer certaines prefs qui doivent sortir de la couche 'computing' et passer au niveau du charts engine
    • attention à la compatibilité avec les TXM déjà installés et les fichiers org.txm.rcpapplication.prefs existants mais de toute façon il faudra sans doute obligatoirement produire un setup, le remaniement est trop conséquent
    • attention au fichier install.prefs (je pense que ce fichier devrait disparaître et que les prefs par défaut devraient être codées en dur, actuellement elles sont codées en dur ET définies dans ce fichier. Si on garde ce fichier je crois qu'il faudrait au moins ne plus les codées en dur et les récupérer depuis ce fichier)
    • en profiter pour rendre fonctionnel le système RCP de préférences par défaut, actuellement la commande de l'UI RCP “Restaurer les valeurs par défaut” dans les prefs ne fonctionne pas ou pas bien
  • définir les plugins qui sont obligatoires et les plugins qui sont optionnels
  • définir si le charts engine devient un plugin obligatoire et/ou si on éclate les fonctions de génération de graphiques dans chaque plugin
    • (a priori oui pour l'éclatement et oui pour la non optionnalité de la base abstraite du code)
    • utiliser le concept de Renderers/Producers/ChartsCreators. En créer pour chaque type de graphique et qui seront donc stockés au niveau du plugin de la fonctionnalité. Stocker dans le charts engine une pile de Renderers/Producers. Définir une méthode du type createChart(Object object), l'object ici serait majoritairement un objet de type TXMResult mais a priori tous les résultats dans TXM n'héritent pas de TXMResult, à revérifier. Voir aussi comment passer les paramètres à cette méthode car actuellement les méthodes du type createProgressionChart() prennent beaucoup plus de paramètres que l'objet Progression. Ensuite, par exemple un truc du style dans createChart(), getRendererFor(progression).createChart() ⇒ commencer par tester dans WordCloud
  • définir si on tente de réintroduire une abstraction des moteurs de corpus et de statistiques
  • une fois le découpage en packages fait et que tout fonctionne, commencer le découpage des packages en projets/plugins et créer les projets de features associés
    • définir si on crée des fragments par langue pour chaque plugin
    • trouver un moyen de partager une licence commune pour chaque plugin/feature (sinon il faudra la réinsérer dans chaque plugin ce qui complexifie encore le travail)
    • commencer sans doute par la TBX
    • le découpage de l'UI/RCP sera sans doute très long, notamment la division du fichier plugin.xml (extensions, etc.)
      • définir ce qui sera partagé dans plugin.xml et qui sera donc inclus dans le projet de base (plugin 'root/hôte')
  • créer des plugins de type wrapper pour chaque lib tierce (valorisation : ajouter dans chaque plugin les licences sources des libs afin qu'elles soient accessibles depuis l'interface de TXM)
    • org.txm.libs.batik
    • org.txm.libs.groovy-all
    • etc.
public/plugins_structure.txt · Dernière modification : 04/07/2017 11:23 de matthieu.decorde@ens-lyon.fr