
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Lire la suite de cet article »

La revue de presse de l’actualité Java/JEE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Lire la suite de cet article »
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 »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
SOA
Le coin de la technique
Lire la suite de cet article »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »

La revue de presse de l’actualitéava/J2EE hebdomadaire proposépar Xebia.
Actualité éditeurs / SSII
Agilité
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
SOA
Mobilité
Le coin de la technique
Évènements de notre communauté en France et à l’étranger
Lire la suite de cet article »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
SOA
Le coin de la technique
Lire la suite de cet article »

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
SOA
Le coin de la technique
Lire la suite de cet article »