L’injection dans Eclipse 4

L’injection dans Eclipse 4

Dans tous les tutoriaux que l’on peut trouver sur Eclipse 4, beaucoup considèrent que le lecteur manipule depuis longtemps les annotations et l’injection, et peu d’informations sont données sur le fonctionnement interne de tous ces mécanismes.

Le but de ce premier article est de démystifier les annotations et leur fonctionnement, et notamment celle pour le mécanisme de base de l’injection.

Je détaillerai ensuite dans un autre article comment utiliser les autres annotations.

J’espère qu’il vous aidera à mieux comprendre la puissance de ce concept et l’intérêt de les utiliser dans Eclipse 4.

Qu’est ce qu’une annotation ?

L’annotation est définie par le langage Java dès sa version 1.5. Il s’agit simplement d’un élément du langage qui peut être associé à une classe, une méthode, un constructeur, un champ ou un paramètre.

Elle se définit dans un fichier java du nom de l’annotation, et se déclare avec la notation @interface. L’annotation doit aussi définir sa cible d’application directement dans sa définition. Par exemple l’annotation d’injection est définie de la manière suivante :

Cette définition se fait également par des annotations réservées pour les annotations !

Il est également possible de définir des annotations avec des paramètres, en créant à l’intérieur des méthodes donnant le type de la valeur et leur valeur par défaut. Par exemple, l’annotation de préférence d’Eclipse 4 est définie de la manière suivante :

Je ne développerai pas plus la déclaration des annotations en Java, de nombreux articles le font déjà, l’essentiel étant de retenir qu’une annotation s’applique à une cible et peut donc être utilisée par la suite, en utilisant l’introspection Java.

Le rôle de l’introspection java.

Les annotations n’ont aucun comportement dynamique associé dans le langage. Pour leur donner un sens, il faut qu’à un moment donné, la classe contenant les annotations soit introspectée pour analyser ses annotations et pour lui appliquer un traitement particulier.

Ce traitement peut, par exemple, intervenir lors de la compilation de la classe pour générer du code complémentaire. Dans ce cas, c’est le compilateur qui analyse le code, et effectue le comportement.

Il faut donc bien comprendre que les annotations ne sont rien sans un traitement derrière qu’il faut effectuer.

C’est donc, lors du runtime, qu’Eclipse 4 va exploiter les classes annotées qu’il va traiter au moment voulu !

Toute la difficulté est donc de connaître ces moments et de savoir à quoi vous avez accès. Eclipse 4 dispose d’un renderer qui permet d’afficher votre application décrite dans le modèle d’application.

C’est donc ce renderer qui va analyser la classe traitée à un moment donné (par exemple un Part est analysé au moment de l’affichage d’une perspective), et qui va ensuite appeler les méthodes possédant telle ou telle annotation.

Tout se passe donc par introspection et la logique séquentielle de votre programme va en être un peu bouleversée (la recherche dans la pile d’appel lors du debug aussi !).

Prenons l’exemple de l’annotation @PostConstruct, que l’on peut poser sur une méthode. Il faut savoir que cette méthode ne sera appelée qu’une fois et après que tous les comportements d’injection aient été appliqués (j’y reviendrai tout à l’heure).

Donc si on ne connait pas la logique du moteur qui exploite les annotations, il va être difficile de comprendre le séquencement d’appel et les endroits où annoter.

Détaillons donc maintenant un peu plus le fonctionnement de l’annotation d’injection, qui est la base de tout le système, et qui est également implicitement utilisée par toutes les autres annotations ensuite.

L’annotation @Inject

Le mécanisme d’injection consiste à déléguer l’instanciation des objets à un injecteur qui aura pour rôle ensuite d’injecter les instances créées aux endroits voulus.

Comme je l’ai dit précédemment, cette annotation ne peut fonctionner que si elle est exploitée dans un processus d’instanciation géré par l’injecteur.

Donc si vous avez écrit une classe avec des annotations @Inject, n’espérez pas que le mécanisme soit pris en charge, si vous instanciez votre classe avec un ‘new’ traditionnel en java !

Il faudra appeler l’injecteur (Cf ContextInjectionFactory) pour construire chaque objet afin que ses annotations soient traitées. Le contexte d’injection peut alors être reçu par … injection ! Le schéma suivant résume la situation :

Concernant l’ordre d’appel, l’annotation @Inject fonctionne de la manière suivante :

1. appel du constructeur
2. initialisation des champs
3. appel des méthodes injectées.

On obtient donc la situation suivante :

Il faut faire attention, car la logique est encore subtile pour chaque partie :

1. Appel du constructeur

Il se fait directement par l’injecteur. Mais quel constructeur choisir si plusieurs ont été définis puisqu’on ne l’appelle pas explicitement ?

Pour le constructeur, l’injecteur va choisir celui qui possède une annotation d’injection et qui possède le maximum de paramètres injectables. Ainsi si vous avez un constructeur avec 3 paramètres, dont 2 seulement peuvent être injectés, ce constructeur ne sera pas appelé.

Autre petite caractéristique qui a son importance, le constructeur n’a jamais accès aux champs injectés de la classe ! Car ils seront initialisés après son appel. Par contre, il peut manipuler les champs qui ne possèdent pas d’annotation @Inject.

2. Injection des champs

Chaque champ de la classe, précédé d’une annotation @Inject sera initialisé, une fois le constructeur appelé et ayant marché (s’il y a eu une exception, tout s’arrête)…

Si un champ ne peut pas être injecté (valeur nulle), l’injecteur génère une exception.  Si ce cas peut se produire, il faut précéder le champ de l’annotation @Optional.

Si votre objet a des champs hérités injectés, ces derniers seront initialisés avant.

3. Appel des méthodes injectées.

L’instanciation de la classe possédant les annotations va se terminer par l’appel de chaque méthode possédant une annotation @Inject.

Tous les paramètres attendus par ces méthodes doivent pouvoir être injectés (à moins qu’il soient précédés d’une annotation @Optional) sous peine d’exception.

L’ordre d’appel des méthodes injectées est indéterminé. Toutefois, les méthodes injectées héritées sont appelées avant celles de la classe.

Et voilà votre objet a été initialisé automatiquement intégralement… mais ce n’est pas tout !

Un comportement supplémentaire  à connaître :

C’est aussi là que l’injection apporte sa magie, car chaque méthode sera réappellée automatiquement, si l’un de ses paramètres change, et ce, à tout moment. De même un attribut injecté sera remis à jour automatiquement si la dernière valeur injectée a changé. Ainsi si vous définissez une méthode @Inject dont l’un des paramètres est par exemple la sélection courante, cette méthode sera appelée à chaque modification de la sélection courante.

Ce mécanisme fonctionne avec tous les objets reçus et remplace partiellement le mécanisme des listeners, plus traditionnel en Eclipse 3.

Ainsi dans l’exemple suivant :

la méthode sera appelée lors de la construction de l’objet qui la contient, mais également à chaque moment où l’un des deux objets passés en paramètre change de valeur dans l’injecteur. Pour ce cas, l’Adapter ne changera pas, car c’est un service global dans Eclipse 4, par contre, la sélection active (passée avec une annotation @Named), changera régulièrement, et sera automatiquement réinjectée dans cette méthode !

Remarque : On notera dans cet exemple, que le paramètre injecté étant de type ‘Object’, il doit être récupéré par un nom unique, qui, dans notre cas de sélection, est fourni par l’interface IServiceConstants d’Eclipse 4. Il serait aussi possible de remplacer le type Object attendu, par le type Rental. Dans ce cas, la méthode ne sera appelée que si la sélection courante est une instance de Rental.

Voilà donc l’une de subtilités de l’injection qui est aussi utilisée dans Eclipse 4 ! Et attention, là nous n’avons décrit que le mécanisme d’injection, nous n’avons pas encore parlé des annotations spécifiques utilisés par le renderer (objet d’un autre article).

Quatre annotations complémentaires pour finir.

Mais l’annotation @Inject seule ne suffit pas à couvrir tous les cas. En effet, l’ordre d’appel des méthodes annotées avec @Inject n’étant pas déterminé, il peut être difficile de s’y retrouver. Certains paramètres également peuvent correspondre à plusieurs instances possibles dans l’injecteur, ou peuvent être optionnels. Le développeur dispose donc d’annotations complémentaires permettant de traiter ces différents cas.

@PostConstruct

Cette annotation ne s’applique que sur une méthode qui sera appelée une fois toutes les injections terminées.  Cette annotation permet ainsi de finaliser l’initialisation d’un objet. Elle est utilisée par exemple pour créer le contenu d’une vue dans Eclipse 4, pour initialiser un Addon, pour brancher des listeners, …

@PreDestroy

Comme @PostConstruct, elle ne s’applique que sur une méthode qui sera appelée juste avant la destruction d’un objet. On peut se servir de cette annotation pour indiquer une méthode qui enlevera les éventuels listeners, ou qui gérera les subtilités de désallocation.

@Optional

A mettre devant un paramètre de méthode injecté ou un champ de classe injecté, pour indiquer que l’on gère le fait qu’il n’y ait pas de valeur.  N’oubliez pas que si aucune valeur ne peut être injectée, une exception sera levée.

@Named

Permet, associé à un nom passé en paramètre de l’annotation, de retrouver un objet nommé stocké dans l’injecteur. On utilise cette annotation quand le type recherché peut avoir plusieurs instances possibles.

Que peut on finalement injecter ?

Là il faut aussi être intuitif, et on peut arriver à s’en sortir presque à chaque fois avec un peu de réflexion (c’est le cas de le dire ! )…

Déjà il faut bien comprendre qu’Eclipse va gérer pour vous des contextes d’injection (IEclipseContext), hiérarchiques, initialisés au fur et à mesure des traitements.

Par exemple, quand l’application démarre, un contexte global est créé. Ce contexte va contenir tous les services OSGi utilisés par Eclipse 4. Puis quand le renderer va s’exécuter, il va créer un contexte pour l’application model (fils du contexte principal). Ensuite, une perspective se créé, elle aura aussi son propre contexte, relié au contexte parent. Idem pour le Part.

Donc, logiquement, le renderer va vous fournir les instances nécessaire pour que votre méthode puisse fonctionner.

C’est pour cela que si on injecte une instance de Component dans la méthode de création du contenu d’une vue, ce Component est forcément le parent dans lequel la vue doit se créér ! Ce n’est pas magique . C’est le comportement dynamique du renderer qui à un moment donné, l’initialise pour vous.

Si vous arrivez ensuite dans un autre part, le Component injecté sera bien sur différent !

On peut donc se dire, que si on a besoin de quelque chose à un endroit, normalement il est disponible !

Plus précisément, dans Eclipse 4, les objets fournissant un nouveau contexte dans le cadre de l’application model, héritent de l’interface MContext. On trouve par exemple, MApplication, MWindow, MPerspective, MPart, MPopupMenu. Sur chacun de ces objets, on pourra récupérer le contexte en appelant la méthode getContext().

Dans un prochain article je vous détaillerai les autres annotations d’Eclipse 4 (et le moment où celles ci sont utilisées !), ainsi que la manière de gérer vos contextes.

Eclipse 4

Eclipse 4 (Juno) est à présent disponible et devient l’architecture officielle pour développer des applications RCP. En parallèle, la version 3.8 permettra jusqu’à juin 2013, de conserver vos anciennes applications et surtout d’attendre la stabilisation d’Eclipse 4.

Nous entrons donc dans une année de transition, où le choix du développement directement en Eclipse 4, doit se faire en connaissance de cause.

Pour vous aider dans votre décision et dans vos migrations, OPCoach a mis à jour ses plans de formation Eclipse 3.X pour présenter en détail la nouvelle architecture, et les actions à mener pour porter votre application.

Un nouveau plan de formation entièrement basé sur Eclipse 4 est également disponible ainsi qu’une formation complète pour vous aider à migrer votre application. N’hésitez pas à me contacter pour plus de renseignements.

Présentation Eclipse 4 lors de l’Eclipse Day à Toulouse

L’Eclipse Day 2012 à Toulouse a été un grand succès avec environ 200 participants.

De nombreuses présentations ont eu lieu mais je n’ai malheureusement pas pu toute suivre, tellement il y avait de gens à rencontrer !

Comme annoncé lors de ma présentation, voici le lien sur le document PDF de la présentation Eclipse 4.

• Présentation Eclipse 4 en français
• Présentation Eclipse 4 en anglais

Je vous propose de commenter cet article si vous avez des remarques sur cette présentation. En effet, j’ai eu des retours lors de discussions informelles, mais il serait bien de les tracer pour en discuter ensembles !

N’hésitez donc pas à commenter ce post !

svn2git : 3 commandes pour migrer de svn vers git

Faire un svn2git facilement… en 5 minutes, votre poussiéreux repository svn sera migré directement sur github ou bitbucket !

Le but de cet article n’est pas de vous former à GIT, ni de vous convaincre de l’utiliser, mais de vous montrer qu’il est très simple de migrer dessus si vous utilisez SVN …

Si vous n’avez pas encore étudié GIT, achetez vous le livre Pro Git !

Outre les avantages techniques de GIT, son utilisation dans Eclipse vous fera gagner aussi du temps puisqu’il est livré nativement dans Eclipse (comme CVS), et donc plus besoin de chercher et d’installer les SVN à chaque changement de version d’Eclipse !

Si tous vos sources sont gérés dans SVN vous vous dites surement, on verra plus tard … Pourtant tout migrer dans GIT peut se faire en 3 commandes git en ligne, tout en conservant tout votre historique SVN. Ces commandes les voici (à lancer dans un répertoire vide) :

git svn clone -s VOTRE_URL_SVN  .                     (ne pas oublier le ‘.’ à la fin)

git remote add origin VOTRE_URL_GIT            (par ex : git@github.com:compte/repo.git)

 git push origin master

Et c’est terminé vous êtes dans la branche master et vous pouvez descendre votre projet dans Eclipse en y accédant avec votre URL GIT.

Et pour obtenir un compte GIT gratuit, 3 solutions s’offrent à vous :

• github : si votre projet est open source… tous les repositories gratuits y sont publics
• bitbucket : jusque 5 repositories privés gratuits (jusque 10 utilisateurs), ou repositories publics.
• serveur interne : à vous de l’installer …

N’hésitez pas à commenter cet article avec vos remarques

Eclipse Day à Toulouse le 24 mai 2012

L’Eclipse Day Toulouse 2012 aura lieu le 24 mai à l’hôtel Palladia, 271 Avenue de Grande Bretagne.

Le planning de cette journée vous donnera un aperçu des thématiques couvertes. Vous pourrez notamment percevoir les tendances technologiques à venir en assistant aux présentations de  Modeling, XText ou Eclipse 4 (que je présenterai).

Le projet Polarsys sera également présenté. Ce projet a pour but d’héberger du code embarqué open source tout en fournissant une maintenance à très long terme (50 ans et plus !). Il vous montrera également l’intérêt que portent de grosses industries aéronautiques pour le monde open source.

N’hésitez donc pas à vous y inscrire pour avoir des retours d’expériences de l’utilisation d’Eclipse dans l’industrie, mais aussi pour rencontrer les membres de la communauté et les acteurs économiques nationaux et européens.

Vous pouvez télécharger le PDF de ma présentation Eclipse 4 en allant sur cet article.

Comment surcharger proprement le code EMF généré ?

Tous les conseils indiqués dans cet article ont été implémentés dans un plugin accessible sur github à cet endroit : https://opcoach.github.io/genModelAddon/

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 :

• 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 !

10 conseils pour travailler en équipe avec Eclipse

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

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 : https://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

10 liens intéressants sur Eclipse

Bonne année 2012 !

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 !

5 bonnes raisons d’aller à             Eclipse Con 2012

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

Retours sur Eclipse Con Europe 2011

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 :

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.

Eclipse Con 2011

Afin d’augmenter et de mettre à jour ses compétences, OPCoach sera présent à Eclipse Con 2011, la conférence annuelle Eclipse qui aura lieu à Santa Clara en Californie.