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 :

• séparer clairement le code généré du code manuel
• générer le code automatiquement dès le process de build
• retirer le code généré de la gestion de configuration (cvs, svn, git, …) et le régénérer lors de la livraison

EMF et Eclipse proposent des solutions simples pour répondre à ce besoin.

1. Séparer le src-gen et le src

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

 2. Générer le code durant le build, dans Eclipse

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 :

3. Générer le code durant le build, hors Eclipse

Dans le processus de build headless, sans avoir un IDE Eclipse lancé, on peut regénérer le code de deux manières

• par l’application org.eclipse.ant.core.antRunner qui rappelle le ant de génération, pouvant contenir d’autres taches
• par l’application org.eclipse.emf.codegen.ecore.Generator qui ne fait que de la génération

Dans les deux cas, il faut initialiser l’environnement de lancement :

• cd {répertoire Installation Eclipse Modeling}
• export LAUNCHER=plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar

Générer  avec le antRunner :

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.

Générer avec le ecore.Generator

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 :

• export PROJECT_HOME={path to your project}
• java -jar $LAUNCHER -application org.eclipse.emf.codegen.ecore.Generator -projects $PROJECT_HOME -model -nosplash $PROJECT_HOME/model/rental.genmodel   $PROJECT_HOME

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 !

Cet article vous donnera 10 conseils pour vous guider dans l’uniformisation de vos postes de développement.

1. Installation d’Eclipse

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 :

• lister dans un wiki, les updates sites des outils complémentaires à installer et diffuser l’information
• installer les compléments dans un Eclipse fraichement téléchargé, et faire installer cette version (gérer les différentes plateformes s’il y a des développeurs sur windows/linux, etc…)
• proposer un update site interne, regroupant tous les outils à installer

Dans tous les cas, il faut s’assurer que chaque développeur travaille bien avec les mêmes versions d’outils.

2. Gestion du workspace

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éé.

3. Réglages Java

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.

4. Formattage du code

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 !

5. Partage des préférences du workspace

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.

6. Commit des fichiers de gestion d’Eclipse

Eclipse stocke dans le répertoire du projet quelques fichiers de configuration nécessaires à son fonctionnement. On trouve notamment :

• le fichier .project contenant les informations du projet
• le .classpath si le projet est de nature java
• le .cproject si le projet est en C/C++
• le répertoire .settings contenant les propriétés des ressources.

Ces fichiers doivent être commités dans la gestion de configuration afin de les retrouver sur chaque poste de développement.

7. Partage des configurations de lancement

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.

8. Gestion de la target platform

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 :

9. Utilisation des ‘working sets’

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 .

10. Export du workspace pour le partager

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 :

• installer un Eclipse avec ses outils
• importer les préférences communes
• importer le fichier team project set du projet

Il s’agit d’une formation inter entreprise organisée en 2 parties :

• Eclipse RCP sur 4 jours : 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.
• Eclipse EMF sur 1 jour  : permettra de maitriser 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.

Il est possible de s’inscrire à la session complète, ou à chaque session séparément.

Les tarifs sont les suivants :

• 2800 € HT pour la formation complète
• 2250 € HT pour la formation Eclipse RCP
• 600 € HT pour la formation Eclipse EMF

Si vous en avez d’autres, n’hésitez pas à rajouter un commentaire !

Il s’agit d’une formation inter entreprise organisée en 2 parties :

• Eclipse RCP sur 4 jours : 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.
• Eclipse EMF sur 1 jour  : permettra de maitriser 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.

Il est possible de s’inscrire à la session complète, ou à chaque session séparément.

Les tarifs sont les suivants :

• 2800 € HT pour la formation complète
• 2250 € HT pour la formation Eclipse RCP
• 600 € HT pour la formation Eclipse EMF

Beaucoup de technologies à explorer : Xtext, Xtend, Eclipse 4…

L’année 2012 sera vraiment très intéressante !

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 !

1. Un voyage beaucoup moins fatigant ! Un vol Paris San Francisco c’est 11h30 de vol, et 8 à 9 h de décalage horaire. Un vol Paris Washington, ce n’est plus que 8h30 et seulement 5 à 6 h de décalage. Le retour est aussi forcément moins fatigant ! Coté tarif, par contre, on est au même prix ! Si on regarde CDG->SFO du 24/3/11 au 30/3/11 par exemple, on est à 650 € sur Air France, et au même prix pour CDG->IAD ! Comme quoi les tarifs sont toujours aussi incompréhensibles ! Comparativement à un Toulouse Paris en tarif plein pot, ce n’est que 150 € de plus !  Mais en cherchant bien, on pourra trouver des vols un peu moins cher…
2. La qualité des présentations. Chaque année, l’Eclipse Con nous propose un contenu de grande qualité et sur des supports variés : retours d’expérience, tutoriaux, présentations courtes ou longues, Bof (réunion informelles le soir sur un sujet), etc… Tous les sujets d’Eclipse sont traités, et quelque soit la technologie que vous utilisez, vous trouverez toujours une présentation pour vous. Vous pouvez consulter le planning des sessions ici, et celui des tutoriaux ici.
3. La rencontre de l’éco système Eclipse. La conférence réunit plusieurs centaines de personnes travaillant directement sur Eclipse et venant d’un peu partout dans le monde. C’est l’occasion de rencontrer des chefs de projets Eclipse, des commiters, des industriels, etc… Tout ceci dans le cadre formel de la conférence ou dans un cadre moins informel autour d’une bière…
4. Le suivi des tendances. Quelle technologie utiliser en 2012 ? Eclipse 4 va devenir l’architecture officielle en Juin 2012. Comment préparer ses migrations ? Quel système de build utiliser ? Qu’apportera Xtext dans les futurs développements ? Et le langage Xtend que peut on en faire ? En allant à cette conférence, vous pourrez assister à de nombreuses présentations vous donnant un état des lieux et des tendances futures des outils.
5. Le tourisme ! Eh oui, il faut bien profiter d’un déplacement aussi loin pour visiter un peu les alentours… Avant ou après la conférence, vous pourrez profiter de Washington et de tous ses musées gratuits (dont le musée de l’air et de l’espace où vous pourrez voir la vraie capsule Apollo XI qui est revenue sur terre!), regroupés aux alentours du congrés et de la maison blanche. En prenant un train ou une voiture, vous pourrez aussi remonter jusqu’à New York et en profiter pour faire quelques emplettes avec un cours du dollar toujours intéressant.

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 :

Maven Tycho :

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 :

• la compilation d’un plugin
• la construction et l’exécution des tests
• la gestion d’une feature
• la gestion d’un repository p2
• la gestion d’un produit
• et la gestion de la target platform

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 :

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.

Visualisation graphique d’un modèle.

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.

RCP en RAP

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.

Acceleo

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 :

• gestion de modules dynamiques (par point d’extension), permettant de surcharger des modules existants.
• la fenêtre ‘interpreter’, permettant sur un objet du modèle d’interpréter des expressions acceleo et de voir le résultat
• la gestion des breakpoint dans les modules et l’intégration parfait du debugger
• la gestion de l’override d’un template (permet de surcharger localement un template).
• la notion de tracability permettant de retrouver le template d’origine d’un fichier (à activer dans la launch configuration)
• le génération pattern, permettant de générer autant de templates que de classes du meta modèle
• de nombreuses fonctions de refactoring : création de template sur sélection, quick replacement
• l’utilisation de [getProperty] pour configurer un template sans lui ajouter plein de paramètres

De nombreuses vidéos complémentaires sont disponibles sur le site d’obeo network.

XCore

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 …).

TMF

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.

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.

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.