Outils pour utilisateurs

Outils du site


public:plugins_structure

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
public:plugins_structure [2014/12/07 14:20]
sebastien.jacquot@univ-fcomte.fr
public:plugins_structure [2017/07/04 11:23] (Version actuelle)
matthieu.decorde@ens-lyon.fr Links to prive:nommage_symboles_externalisation changed to public:nommage_symboles_externalisation
Ligne 10: Ligne 10:
  
 Ce développement est étroitement lié à l'​architecture des préférences TBX et RCP, voir : [[public:​preferences_system|Architecture des préférences TBX et RCP]]. Ce développement est étroitement lié à l'​architecture des préférences TBX et RCP, voir : [[public:​preferences_system|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 ?). Il faudra ensuite notamment revalider toutes les fonctionnalités de TXM.+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 ===== ===== Solution =====
Ligne 29: Ligne 31:
  
 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. 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 ==== ==== Proposition de structuration des packages, exemple pour la commande CA ====
Ligne 89: Ligne 93:
       * CAPreferencesPage.java       * CAPreferencesPage.java
       * CAPreferencesStore.java       * CAPreferencesStore.java
-    * searchengine +    * searchengine ​(inutile dans les plugins RCP ?) 
-    * statsengine+    * 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 : [[prive:nommage_symboles_externalisation|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 ?+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_symboles_externalisation|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 '​root'​ dans les projets '​root'​ TBX (org.txm.tbx) et RCP (org.txm.rcp) ====+==== 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.tbx.base
   * org.txm.rcp.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
 +
  
  
Ligne 104: Ligne 171:
  
 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: 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.   * 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     * 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   * 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
-    * en profiter pour renommer les symboles/​constantes liés aux chaînes avec des noms explicites (voir les symboles utilisés par exemple dans le charts engine où j'ai essayé d'​être explicite)+    * en profiter pour renommer les symboles/​constantes liés aux chaînes avec des noms explicites (voir les symboles utilisés par exemple dans le charts engine où j'ai essayé d'​être explicite ​[[http://​svn.code.sf.net/​p/​txm/​code/​trunk/​Toolbox/​trunk/​org.textometrie.toolbox/​src/​java/​org/​txm/​tbx/​chartsengine/​base/​messages/​messages.properties]] et la page: [[nommage_symboles_externalisation|Nommage des symboles d'​externalisation]])
   * implémenter un système de Store RCP pour la TBX   * 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   * 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
Ligne 114: Ligne 185:
     * 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 à 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)     * 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 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   * 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)     * (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   * 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     * définir si on crée des fragments par langue pour chaque plugin
Ligne 122: Ligne 196:
     * commencer sans doute par la TBX     * 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.)     * 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'​)+      * 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)   * 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.batik
public/plugins_structure.1417958453.txt.gz · Dernière modification: 2014/12/07 14:20 par sebastien.jacquot@univ-fcomte.fr