Liste de liens :
Liste de liens :
[Proposition SJ à discuter pour le découpage en plugins des projets]
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 :
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).
Ou bien ajouter un sous package comme actuellement ?
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é ?
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 ?
Ceci concerne typiquement le code mutualisé entre toutes les implémentations et le code abstrait.
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)
Plugin CA FactoMineR (implémentation)
Plugin CA (implémentation, package R CA)
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)
Moteur R
Plugin TBX (abstraction R)
Plugin CA FactoMineR (implémentation R)
Plugin CA (implémentation, package R CA)
Moteur Java “light”
Plugin TBX (abstraction si besoin)
Plugin CA FactoMineR (implémentation Java)
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.