je me permet de poster un petit appel a la bonne volonté.
Le projet EMFT Search aurai quelques améliorations ou correctifs assez sympas pour des développeurs motivés.
A la clef, sa photo sur la page hall of fame Eclipse Modeling en tant que contributeur !
En bref, le projet EMF Search définit un framework extensible offrant
des capacités générales de recherche/query/replace (Regex/OCL/...) sur
les modèles Ecore ou basés sur Ecore.
Les implementation
spécifiques de recherche pourraient être générés pour n'importe quel
modèle conforme au méta-model Ecore. Ainsi, par simple connaisance de
la structure d'un modele Lambda : Packages {Toto, Titi, Tata},
Classifiers {X, Y, Z}, il est possible de générer des implementations
(APIs) qui permettent d'invoquer des search/replace spécifiques à ce
modèle :
TotoLaunchRegexQuery(".*", Toto.Literals.X, <URI*s>) qui va
evaluer une "query" regex ".*" sur tout les objets de type [X] dans les
les URIs du scope considéré.
TotoReplaceRegexQuery("^A.*, "^B.*", Toto.Literals.Y, <URI*s>)pour le replace, etc ...
On utilise aussi l'OCL et les possiblités d'évaluations sont extensibles ... XPath, Linq like ?
L'architecture de génération est en cours de dévelopement, bien entamé mais pas finalisée.
Les
autres aspect ont leurs fondements posés mais souffrent des
améliorations et/ou de réelles évolutions. Je suis aussi impliqué dans
le projet EcoreTools qui se veut le creuset d'un futur environement
intégré pour Ecore (relations a voir dasn un deuxième temps). Un autre
projet a manifesté son intéret pour des fonctionalités de Search
(MDT/SBVR
Dans ce cadre, j'aurai besoin de vous en tant que contributeur pour
nous assurer de la finalisation de différents pans du projet. La
contribution sera alors intégrée dans le/les projets Eclipse concernés
et en fonction de besoins vous pourrez rejoindre le projet en tant que
commiter après plusieurs contributions significatives (Necessite de remplir des papiers administratifs pour la
fondation eclipse).
Cela vous permettra sans aucun doute de gagner en compétence dans ces domaines assez a la mode en ce moment ;-)
=================
TRONC COMMUN
===============================================
NB: la création des modeles Ecore est plus aisée en utilisant le projet EcoreTools.
Les objectifs :
1) Prise en main de l'environement utilisateur Eclipse Ganymede 3.4M5 pour les aspects modelisation.
- Download est install de Eclipse Ganymede + EMF Search + EcoreTools avec Update Manager (
http://download.eclipse.org/releases/ganymede/)
- Prise en main EMF : diagraming avec EcoreTools, Modelisation, code generation (avec/sans customisation code)
- Compréhension niveau utilisateur des fonctionalités Search
2) Prise en main de l'environement de dévelopement Eclipse Ganymede 3.4M5 pour les aspects modelisation
- Récupération des sources du projet (CVS :pserver:anonymous@xxxxxxxxxxxxxxx:/cvsroot/modeling)
=> <CVS_MODELING_MODULE>/org.eclipse.rmf/org.eclipse.emf/search/plugins/*
- Faire compiler le code avec les versions de plugins compatibles 3.4M5 récupérés depuis Ganymede Update Manager
==============================================
OPTION A : Generation EMF Search pour Ecore
==============================================
3) Lancement d'un workbench runtime en mode debug et exploration code generation EMF search
- Lancer le deuxieme eclipse, creer un nouveau projet contenant des projets EMF (fichiers Ecore + genmodel correspondant)
- Générer les parties modele, edit, editor
- Utiliser la génération de code EMF Search par click droit sur un fichier GenModel
-
Constater les besoins en terme d'adaptation du code EMF Search généré
en vue d'obtenir une implementation spécifique de Search pour le modele
considéré
4) Adaptation des templates JET
- dans org.eclipse.emf.search.codegen, adapter les templates JET dans .../templates/SEARCH_CORE, ...templates/SEARCH_UI
- Proceder itérativement pour obtenir un code remplissant la fonctionnalité de search pour un modele simple avec un seul package
- première étape a valider par l'obtention d'API de build et launch EMF search viables au runtime
5) Approfondissement
- Mener un reflection quant a une analyse plus "pertinente" du modele EMF source en vue de :
* trouver introspectivement les attributs EString pouvant servir a l'implementation d'une query regex
* Réflechir a un méchanisme général d'évaluation de query basée sur les
types primitifs d'un objet EMF/Ecore complexe à partir d'EMFT query (A
discuter et définir plus tard)
==============================================
OPTION B : Recherche de Design Pattern Structuraux UML
==============================================
3) Lancement d'un workbench runtime en mode debug et exploration recheche EMF Search pour UML
- Lancer le deuxieme eclipse, creer un nouveau projet contenant des projets UML Class Daigram)
- Utiliser la génération de EMF Search pour UML
- Constater les besoins en terme d'adaptation du code EMF Search
pour les design pattern structuraux (Embryon existant)
4) developement des Evaluators custom de recheche de pattern structuraux UML (Composite notement + d'autres ???)
- dans org.eclipse.uml2.search.common, adapter le code des evaluateurs pour specifiquement "matcher" des design patterns
- Proceder itérativement pour obtenir un code remplissant la fonctionnalité de search pour un class diagram simple
- première étape a valider par l'obtention d'API de build et launch EMF search pour UML viables au runtime
5) Approfondissement
- Mener un reflection quant a une analyse plus "pertinente" d'autres design patterns candidats en vue de leur implementation :
-
Quid de la presenation graphique des design pattern trouvés dans la vue
de Résultat, quelles actions de dev a mener pour adapter la structure
de donnée
==============================================
OPTION C : Replace textuel (+ Undo/Redo ?)
==============================================
3) Lancement d'un workbench runtime en mode debug et exploration recheche EMF Search pour UML
- Lancer le deuxieme eclipse, creer un nouveau projet contenant des projets Ecore Diagram)
- Utiliser la replace EMF Search et constater les améliorations a porter
- Constater les besoins en terme d'adaptation du code EMF Search
pour rendre le replace fiable et robuste 100%
4) Maintenance des APIs replace Regex
- dans
org.eclipse.emf.search.ecore/src/org/eclipse/emf/search/ecore/internal/replace/provisional/,
maintenir le code pour remplacer de maniere robuste des régions de
"match" regex par la/les valeur(s) textuelle(s) choisies par
l'utilisateur
- Proceder itérativement pour obtenir un code remplissant la fonctionnalité de search/replace pour tout modele
- première étape a valider par l'obtention d'API de replace EMF search viables au runtime
5) Approfondissement
- Mener une reflection quant au besoin de developement en vue de faire
fonctionner les mécanismes d'UNDO/REDO pour les replace concernés
(see: EMFT Transaction, editong domain, ..)
==============================================
OPTION D : Implementer Ctrl+F pour les editeurs Ecore
==============================================
A voir
==============================================
OPTION E : Maintenir le code des Open EClass, UMLClass
==============================================
3) Lancement d'un workbench runtime en mode debug et exploration recheche EMF Search pour UML
- Lancer le deuxieme eclipse, creer un nouveau projet contenant des projets UML Class Daigram et Ecore)
- Utiliser les raccourcis EMF Search en vue d'ouvrir une EClass,
EPAckage, UML Class , UML Package et constater les améliorations a
porter
(Ctrl+Shit+L pour avoir les shortcuts)
- Constater les besoins en terme d'adaptation du code EMF Search
pour rendre le replace fiable et robuste 100%
4) Maintenance des APIs
- Regarder les implementations de AbstractModelSearchFilteredMetaElementsSelectionDialog
- Modifer les Code de raccourci pour eviter les overlapping avec les autres projets Ganymede
- Proceder itérativement pour obtenir un code remplissant la fonctionnalité de search/replace pour tout modele
- première étape a valider par l'obtention d'API de replace EMF search viables au runtime
5) Approfondissement
- Mener une reflection quant au besoin de developement en vue de décorer les entrées du dialogues de facon plus pertinentes
==============================================
OPTION F : Implementer un Visteur Http pour Ecore
==============================================
3) Lancement d'un workbench runtime en mode debug et exploration recheche EMF Search pour UML
- Lancer le deuxieme eclipse, creer un nouveau projet contenant des projets UML Class Daigram)
- S'inspirer de l'example EMF Search RCP pour definir une requete sur un repository WWW en HTTP
- Constater les besoins en terme d'adaptation du code EMF Search
pour rendre les requetes HTTP recursives sur les directories d'un server distant
4) Maintenance des APIs
- Regarder les implementations de EcoreModelSearchScopeHttpVisitor
- Modifer les Code pour ajouter la récursivité
- Proceder itérativement pour obtenir un code remplissant la fonctionnalité de search/replace pour tout modèle
- première étape a valider par l'obtention d'API de replace EMF search viables au runtime
5) Approfondissement
- Mener une reflection quant au besoin de developement en vue de mixer
different scopes de recherches de façon composite/transparente ?
Bien entendu ces besoins sont définis de façon brute et sont a
pondérer en fonction du temps alloué ainsi que des niveau de
connaisance actuels sur les technologies utilisées.
Ceci n'exclu
en rien de partir sur de la méta modelisation EMF plus ciblée ou sur la
réalisation d'examples ou de tests cases JUnit.
cordialement,
