Utiliser Guice et Peaberry pour développer un plugin Eclipse

Article publié par Nicolas Demengel le 29 décembre 2010.

Catégorie(s) : Java / JEE

 

Aucun commentaire »

Mots-clefs :, , ,

Sans travailler spécifiquement sur la plateforme Eclipse et sans être committeur sur un des projets liés, il n’est pas rare de devoir écrire un plugin pour l’IDE Eclipse. Les raisons peuvent être variées : intégrer le gestionnaire de tâches de votre entreprise, supporter le DSL que vous venez de créer, templater des parties récurrentes de votre développement, etc…

Quand on découvre la plateforme, on peut être surpris par deux différences majeures par rapport au développement d’un projet Java « entreprise » :

  • La manière de builder le projet : Eclipse propose ses propres conventions de structure de projet et fournit ses outils pour le builder. Certains points sont paramétrables mais on ne retrouve pas la richesse offerte par Ant, Maven ou encore Gradle. Cela fera éventuellement l’objet d’un autre article ;
  • Dans le code lui même : le passage des dépendances entre classes ou entre bundles est particulier, et c’est ce dernier point qui nous intéresse dans cet article. En effet le code d’un plugin Eclipse ressemble souvent à ça : SomePlugin.getDefault().getSomeComponent().getSomeChild().doSomething().

Les singletons sont omniprésents, principalement pour fournir un point d’accès aux différents bundles. Par ailleurs beaucoup d’actions ne sont accessibles que via des méthodes statiques.

Évidemment, le principal problème qui se pose est celui des tests unitaires. Eclipse propose de lancer votre plugin et d’exécuter des tests JUnit dessus, mais il s’agit là de tests d’intégration qui s’exécutent lentement et ne permettront pas de faire du TDD. Il est toujours possible de faire de l’injection de dépendances (DI) « à la main », mais on aurait tort de se priver de l’utilisation d’un framework dédié à cela, d’autant plus qu’on pourrait y gagner d’autres fonctionnalités : binding interface/implémentation, gestion de scopes (singleton, session…), AOP, etc…

En attendant Eclipse 4 – qui proposera nativement des fonctionnalités de DI - je vous propose donc de mettre en place Guice et son extension Peaberry sur un projet-type de plugin pour Eclipse.

Lire la suite de cet article »

 

Page optimized by WP Minify WordPress Plugin