EMF permet de générer du code à partir du modèle. En paramétrant un fichier .genmodel, on peut ainsi générer les trois couches de code : model, edit et editor, qui contiennent les sources java permettant d’exploiter le modèle métier défini.
Pour surcharger le code généré la méthode traditionnelle consiste à modifier directement le code généré en ajoutant un ‘NOT’ derrière les balises @generated. Le plugin ‘mint’ (dans emftool), permet également de distinguer les méthodes surchargées (en rouge), les méthodes ajoutées (en noir) et les méthodes générées (en bleu) :
La surcharge de code avec @generated
Cette méthode peut être acceptable si peu de code est modifié, mais dans le cas de projets où beaucoup de code métier doit être ajouté, il est préférable de :
EMF et Eclipse proposent des solutions simples pour répondre à ce besoin.
Pour travailler proprement, il faut prendre des mesures d’étanchéité, en séparant clairement le répertoire du code généré de celui du code surchargé. Pour le faire, on paramètre le genmodel de la manière suivante :
Paramétrage du genmodel
On peut répéter cette opération pour la couche edit et la couche editor.
Puis on créé un répertoire src (source folder), dédié à la surcharge dans le projet :
Répertoire src pour la surcharge
Ce nouveau répertoire de source, va contenir la nouvelle factory EMF pour créer les instances des classes surchargées. Cette factory dérive de la factory générée, et propose des création d’objets avec les nouvelles interfaces :
Nouvelle factory qui créé les nouvelles instances
On complétera les méthodes de cette factory au fur et à mesure qu’on surchargera les classes du modèle généré.
L’implémentation de la factory est alors simplement :
Implémentation de la factory surchargée
Il ne reste plus qu’à relier cette nouvelle factory à EMF, en utilisant le point d’extension factory_override :
Point d'extension override_factory
Cette nouvelle factory sera alors automatiquement utilisée par EMF lors de la création des objets par un appel à RentalFactory.eInstance.
Il reste alors à surcharger les classes métiers modélisées avec EMF. On peut notamment ajouter des méthodes de confort (add, remote) dans les interfaces … :
Ajout des méthodes d'accès dans l'interface
… et surcharger les opérations modélisées dans l’implémentation :
Implémentation des méthodes métier et de l'interface
Si on sépare totalement le code généré du code surchargé, il peut être intéressant d’automatiser la génération du code à partir du modèle.
EMF nous propose une tache ant (emf.Ecore2Java) permettant de générer le code à partir d’un genmodel. Le fichier ant à écrire est trivial :
Fichier ant de génération de code EMF
Pour l’exécuter il faudra faire attention d’utiliser le JRE du workspace (paramètre dans le lancement du build, dans l’onglet JRE).
Ce fichier ant peut alors être intégré au builder du projet en le mettant en première position pour être sûr que le code généré sera présent pour la compilation :
Dans le processus de build headless, sans avoir un IDE Eclipse lancé, on peut regénérer le code de deux manières
Dans les deux cas, il faut initialiser l’environnement de lancement :
Lancement du build ant avec le antRunner :
java -jar $LAUNCHER -application org.eclipse.ant.core.antRunner -nosplash -buildfile {pathToAntFile}/ecore2java.xml
Cette méthode est intéressante si le fichier ant fait un peu plus que de la génération de code.
Cette méthode est intéressante s’il n’y a que du code à générer à partir du modèle :
Les paramètres de l’application sont : java -jar $LAUNCHER -application org.eclipse.emf.codegen.ecore.Generator
Usage arguments: [-projects ]
[-dynamicTemplates] [-forceOverwrite | -diff]
[-generateSchema] [-nonNLSMarkers]
[-codeFormatting { default | } ]
[-model] [-edit] [-editor] [-tests]
[-autoBuild true | false ]
genmodel-file [ target-root-directory ]
Exemple d’utilisation :
Pour approfondir ces notions, je vous conseille aussi cet article général sur le sujet, présenté à infoq et écrit par Sven Efftinge (chef de projet XText)
N’hésitez pas à commenter cet article si vous avez des remarques !
Continuer la lectureVous travaillez en équipe avec Eclipse et vous n’arrivez pas toujours à vous y retrouver entre tous les postes de vos développeurs ? L’installation d’un nouveau poste vous prend du temps ? Vous vous posez des questions sur votre organisation de travail ? Vous pensez que vous pourriez améliorer les choses ?
Cet article vous donnera 10 conseils pour vous guider dans l’uniformisation de vos postes de développement.
Pour bien développer, il est indispensable d’utiliser la dernière version d’Eclipse disponible. Cette version se télécharge sur le site d’Eclipse : http://www.eclipse.org/downloads/
Si la version d’Eclipse téléchargée n’est pas suffisante (par exemple un eclipse modeling, ne contient pas les webtools, ou svn), il faudra gérer les outils ajoutés. Plusieurs manières de faire sont possibles :
Dans tous les cas, il faut s’assurer que chaque développeur travaille bien avec les mêmes versions d’outils.
Eclipse gère les projets dans un workspace auquel sont associés des paramètres appelés préférences.
Chaque projet ayant des caractéristiques différentes selon les clients, il faut gérer un workspace par projet.
Dans le cas de développement sur des branches de maintenance, on utilisera également un workspace dédié pour cette branche.
On passera d’un workspace à l’autre en utilisant la commande ‘File->Switch Workspace…’.
On pourra recopier les préférences d’un workspace à l’autre lors de la création d’un nouveau workspace, ou importer des préférences stockées dans un fichier une fois le workspace créé.
Dans un environnement multi développeurs, les machines et les configurations java sont souvent différentes. Pour éviter les problèmes de configuration, il convient, dès le départ, de bien régler certains paramètres.
Les environnements Java permettent de faire correspondre une version de Java (J2SE-1.5 par exemple) à un JRE ou un JDK installé sur votre machine. Ces environnements sont stockés dans le workspace courant. C’est un des rares réglages manuels à faire sur chaque poste de travail, les autres pouvant être partagés en sauvant les préférences (Cf §5) :
Dans les projets java ensuite (pour les plugins, on ne peut choisir que des environnements), seuls les environnements java doivent être utilisés et référencés. Il ne faut plus utiliser la JRE courante ou un JRE alternatif :
Ainsi, si un développeur récupère un projet par la gestion de configuration et qu’il dispose par défaut d’un JDK 1.5, son projet sera en erreur et il devra régler ses préférences correctement.
Autre réglage important : les règles de formatage de code, qu’il est nécessaire de partager entre tous les développeurs. Si on ne les fixe pas dès le départ, et que les fichiers sont ensuite livrés en gestion de configuration, cela va poser des problèmes lors des comparaisons avec les versions antérieures.
Le réglage, pour java, se fait dans les pages de préférences et l’idéal est d’importer un fichier de préférences commun, propre au projet et partagé sur le réseau (obtenu la première fois en faisant un export all) :
On peut notamment modifier la taille de ligne par défaut qui est fixée à 80 colonnes et qui est maintenant inadaptée vu la taille des écrans !
En exportant les préférences du workspace (Menu Export → Préférences), il est possible et simple de partager les préférences communes d’un projet. Le fichier .epf créé peut ensuite être réimporté sur les autres postes.
Eclipse stocke dans le répertoire du projet quelques fichiers de configuration nécessaires à son fonctionnement. On trouve notamment :
Ces fichiers doivent être commités dans la gestion de configuration afin de les retrouver sur chaque poste de développement.
Quelque soit le type de projet, les paramètres de lancement d’une ‘launch configuration’ peuvent se stocker dans un fichier. On accède au partage, dans l’onglet ‘Common’ de chaque launch configuration. Un fichier ‘.launch’, se stocke dans le projet et peut être commité dans la gestion de configuration. En sélectionnant les menu Run et Debug, les autres développeurs pourront y accéder directement dans les menus.
Lors du développement d’une application RCP, il est nécessaire de fixer la target plateform du workspace.
Le mieux est de créer un fichier target (New Wizard → target Definition), dans le plugin principal de l’application. Bien sur ce fichier sera stocké dans la gestion de configuration (cvs, svn…).
Pour permettre l’utilisation commune des fichiers target, il ne faut pas référencer des fichiers en local, mais plutôt référencer directement les sites Eclipse, ou éventuellement un répertoire partagé accessible.
L’écran de préférences de target platform référence ensuite tous les fichiers .target présents dans le workspace :
Le workspace peut rapidement contenir plusieurs projets, voire plusieurs dizaines de projets. Les ‘working sets’ vont permettre de ranger le workspace en créant des groupes pour rassembler les projets. Un projet peut appartenir à plusieurs ‘working sets’ simultanément.
L’affichage en mode working set, s’effectue dans le menu de la vue package Explorer :
Ce même menu contient aussi les commandes permettant de remplir les working set avec les projets .
Enfin, une fois que le workspace est bien rangé avec les ‘working sets’, il est possible d’exporter son contenu dans un fichier ‘Team Project Set’. Ce fichier contient toutes les URL d’accès à votre gestionnaire de configuration (cvs, svn, …), mais aussi tous les ‘working sets’ définis.
Il suffit qu’une personne définisse un workspace de référence, contenant tous les projets, rangés par working set, et qu’elle exporte ce workspace dans un fichier stocké sur un disque partagé :
Un nouveau développeur, peut alors installer un nouveau poste en 3 étapes :
Continuer la lecture
Comme en février, OPCoach vous propose une formation Eclipse RCP et EMF du 5 au 9 mars 2012 à Toulouse.
Il s’agit d’une formation inter entreprise organisée en 2 parties :
Il est possible de s’inscrire à la session complète, ou à chaque session séparément.
Les tarifs sont les suivants :
Continuer la lecture
| Eclipse, le point d’entrée : download, projects, members, etc… | http://www.eclipse.org |
| Wiki, la documentation sur certains points | http://wiki.eclipse.org/Main_Page |
| Bugzilla, où rechercher un bug si on a un doute ! | https://bugs.eclipse.org/bugs |
| Press release, les annonces officielles de la fondation | http://www.eclipse.org/org/press-release |
| Hudson, le build continu d’Eclipse ! | https://hudson.eclipse.org/hudson |
| Forums, les questions des utilisateurs | http://www.eclipse.org/forums |
| Blog, les nouvelles du jour (très intéressant) | http://planeteclipse.org |
| Conférences Eclipse, aux US et en Allemagne | http://www.eclipsecon.org |
| Webinars, podcast, des ressources pratiques | http://live.eclipse.org |
| Plugin central, le repository des plugins existants | http://marketplace.eclipse.org |
Si vous en avez d’autres, n’hésitez pas à rajouter un commentaire !
OPCoach vous propose une formation Eclipse RCP et EMF du 13 au 17 février 2012 à Toulouse.
Il s’agit d’une formation inter entreprise organisée en 2 parties :
Il est possible de s’inscrire à la session complète, ou à chaque session séparément.
Les tarifs sont les suivants :
Continuer la lecture
OPCoach vous souhaite une excellente année 2012 !
Beaucoup de technologies à explorer : Xtext, Xtend, Eclipse 4…
L’année 2012 sera vraiment très intéressante !
Continuer la lecture
L’année 2012 sera une année importante pour l’Eclipse Con ! En effet, après plus de 8 années de conférence en Californie, principalement à Santa Clara, au sud de San Franciso, la fondation a décidé de déplacer la conférence sur la cote Est, et nous propose une conférence à Reston en Virginie (à coté de Washington).
Ce changement devrait permettre à des nouveaux participants de venir… et ceci m’amène à vous donner 5 bonnes raisons d’aller à l’Eclipse Con 2012 !
Eclipse Con Europe 2011 s’est déroulé à Ludwigsburg en Allemagne, comme depuis plusieurs années…
En parallèle des 10 ans d’Eclipse qui ont été célébrés le premier soir, et des nombreux contacts que l’on peut avoir lors de cet type de conférence, les présentations sont en général intéressantes et permettent de suivre les tendances à venir. Voici un rapide résumé de quelques présentations intéressantes que j’ai pu suivre :
Un tutorial intéressant de 3 heures a été déroulés la première matinée. Très progressif, il a permis d’apprendre à utiliser Tycho pas à pas, en voyant notamment :
Je tiens à votre disposition les fichiers de ce tutorial que je peux vous envoyer si vous me le demandez …
Buckminster vs Maven Tycho (autre outil de build, concurrent) :
L’année dernière Buckminster était encore présenté, mais depuis 1 an, on en entend plus parler (aucune présentation aux deux Eclipse Con de cette année). Cet outil garde toujours son intérêt, même si ses détracteurs le considère comme un outil complexe ! Son seul défaut est d’être malheureusement trop et mal documenté : le ‘buckminster guide’ fait 270 pages, mais il mélange des notions utilisateur et développeur, ce qui a amené à de nombreuses confusions.
Buckminster permet de gérer le build dans un projet à part, en définissant une ‘query map’ unique sur une feature, puis en appelant le build. Maven Tycho, oblige à répandre des pom.xml dans tous les projets, et à configurer de nombreux paramètres dans le projet pom parent. Au final, livrer un produit reste basé, pour les deux technologies, sur le même mécanisme : il faut livrer le repository p2, puis en tirer l’exécutable du produit… Enfin les deux projets s’intègrent parfaitement dans hudson/jenkins à l’aide des plugins appropriés.
Alors que choisir ? Si vous avez un nouveau projet, il faudra s’orienter sur mayen tycho, car il devient le mécanisme de build de référence d’Eclipse, et permet d’utiliser tous les avantages de mayen qui est plus ouvert que buckminster. Si votre projet est déjà basé sur buckminster, tant que ça marche… pourquoi y toucher ?
Eclipse 4 deviendra, en juin 2012 avec la version E4.2, la plateforme officielle de développement Eclipse. En parallèle la version 3.8 sera livrée ce qui permettra d’effectuer les migrations en douceur. E4 fournit une couche de comptabilité permettant de faire fonctionner une application basée sur Eclipse 3.x, sur un runtime E4.
Il n’y a pas eu de présentation révolutionnaire sur Eclipse 4 à cette conférence… A part quelques rappels sur l’architecture (ihm déclarative, CSS, injection, gestion des traductions, … ), les présentations n’ont pas montré de nouveautés.
Parallèlement à GMF, GEF, Zest qui nous fournissent des technologies graphiques d’affichage ou d’édition, Itemis a fait une présentation novatrice sur une nouvelle manière de représenter graphiquement un modèle. Leur idée est de définir, à l’aide d’XText, un nouveau fichier descripteur (gvmap) de la visualisation graphique.On indique dans ce fichier les noeuds et connexions en se référant aux objets du modèle. Leur vue de display permet de constater directement les modifications. Cet outil ne permet pas d’obtenir un éditeur graphique du modèle, mais juste une représentation. Il se situe au même niveau que Zest ou que GEF en mode display.
Vitaphone GmbH a fait une présentation intéressante de leur outil de gestion d’informations médicales partagées par des médecins, infirmières, etc… Ayant 6 différents types d’affichages différents (PC, Tablettes, Iphones, …), ils ont optés pour la technologie RAP pour s’affranchir des problèmes de développement WEB. Plus d’ajax, de javascript et 99 % de single sourcing. Leur application RCP, contenant également des courbes JFreeChart, a pu être intégralement publiée sur le WEB grâce à RAP. Ayant une BDD derrière l’application, ce type d’architecture est parfaitement adapté (RAP ne permet pas de gérer les fichiers). Leur seule mise en garde est que cela fonctionne bien pour quelques dizaines de connections, mais qu’il ne faut pas utiliser cette technologie pour de gros portails.
Obeo a présenté les dernières nouveautés des éditeurs Acceleo. De nombreuses fonctionnalités très utiles pour l’édition de templates de génération de code sont désormais intégrés dans Acceleo, qui s’impose comme l’outil de référence pour générer du code à partir de modèles. On peut remarquer notamment :
De nombreuses vidéos complémentaires sont disponibles sur le site d’obeo network.
Ed Merks et Sven Efftinge ont présenté XCore. Edité à l’aide d’un éditeur Xtext, XCore permet d’éditer un méat modèle Ecore en utilisant une syntaxe proche de java. Intéressant, car il va permettre d’éditer textuellement des méat modèles avec un éditeur évolué (qui remplacera emfatic, un peu rustique…). Autre point intéressant, la syntaxe permet d’ajouter du code dans le modèle (validation, initialisation d’un énuméré selon l’état de l’instance, etc …).
Cette présentation technique, a montré comment intégrer des éditeurs Xtext à l’intérieur d’éditeurs graphiques GMF. Intéressant pour enrichir un éditeur avec de l’édition évoluée. Ces éditeurs peuvent apparaitre dans les zones de texte graphiques, ou dans les propriétés.
Continuer la lecture
Comme chaque année, Zenika organise une journée de rencontre autour d’Eclipse.
L’Eclipse Day se déroulera le 8 novembre 2011 au palais royal à Paris. C’est un événement gratuit. N’hésitez pas à vous y inscrire pour y rencontrer les acteurs de l’éco système Eclipse en France.
OPCoach sera présent à cet événement.
A bientôt.
Continuer la lecture
Pour cette fin d’année, OPCoach vous propose une semaine complète de formation aux technologies Eclipse, pouvant être prise en charge à 100 % dans le cadre de l’ADEC !
Il s’agit d’une formation inter entreprise organisée à Toulouse du 5 au 9 décembre 2011.
La première partie de 4 jours, sur Eclipse RCP, permettra de maitriser tous les concepts de cette puissante architecture devenue incontournable pour les développements Java. Le plan détaillé de cette partie est disponible ici.
La seconde partie permettra de connaitre le projet EMF : son langage Ecore de modélisation et ses outils de génération de code associés. Cette journée complète parfaitement la formation RCP afin d’être directement opérationnel et productif lors de vos développements. Le plan détaillé de cette journée peut être consulté ici.
Concernant le financement, un accord a été passé en juillet 2011 entre l’état et les organismes de financement des formations (OPCA), permettant de prendre en charge 100 % de cette formation. Si votre société est adhérente au fafiec par exemple, les modalités sont expliquées dans ce document, ou dans celui ci.
Le tarif pour la formation complète est de 2800 € HT. Pour la formation uniquement RCP, le tarif est de 2250 € HT, mais elle ne pourra pas être prise en charge par l’ADEC car elle ne fera pas 35 heures.
N’hésitez pas à me contacter pour tous renseignements complémentaires : olivier.prouvost@opcoach.com
PS : Vous pouvez télécharger d’un seul coup tous les fichiers relatifs à cette formation en cliquant sur ce lien.
Continuer la lecture
