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

La revue de presse hebdomadaire des écosystèmes Java/JEE 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 hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Actualité éditeurs / SSII
Agilité
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 hebdomadaire des écosystèmes Java/JEE 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é Java/JEE hebdomadaire proposée par Xebia.
Agilité
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/JEE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
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
Notre communauté en France et à l’étranger
Lire la suite de cet article »
En ce beau matin d’hiver, me voilà bien décidé à effectuer un peu de ménage sur notre projet. Ma cible d’aujourd’hui : la chasse aux warnings.
Grosso modo, j’observe qu’il y a 3 types de warning :
- imports inutilisés (60%)
- unchecked casts (30%)
- variables ou méthodes private non utilisées (10%)
Je prends mon bâton de pèlerin et je nettoie. Cependant, je me rends bien compte que ces warnings sont pour la majorité des erreurs d’inattention qui pourraient être facilement évitées.
A quoi bon nettoyer, si c’est pour se retrouver dans la même situation dans trois mois ? Donc, en plus de ma maintenance corrective, je pars également à la recherche d’une action préventive.
Première idée évidente, configurer Eclipse pour que celui-ci effectue ce genre de nettoyage lors d’une sauvegarde d’un fichier. Facile, il suffit de paramétrer ceci dans Properties -> Java Editor -> Save Actions (Plus de détails ici).
Cependant, à quoi bon le faire uniquement sur mon Eclipse ? Quel intérêt, si les autres membres de l’équipe ne bénéficient pas eux aussi de la même configuration ? Comment faire en sorte que ma configuration soit facilement partagée avec les autres ?
Le projet étant un projet maven, le maven-eclipse-plugin semble offrir la solution.
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 »
Et c’est parti pour les Tools in action avec pour ma part la session Augmenter votre productivité avec Mylyn de Oliver Gierke, SpringSource.
Mylyn, c’est le framework ALM (Application Lifecycle Management) d’Eclipse. Il réorganise tout l’IDE autour de tâches. Celles-ci seront ensuite traduites par Mylyn pour nos différents outils comme notre gestionnaire de sources, notre intégration continue ou bien encore notre bugtracker. Le développeur pourra ainsi ne se préoccuper que de ses tâches, Mylyn s’occupant du reste.
Oliver Gierke nous oriente vers 3 grands domaines concernant cette fameuse productivité recherchée du développeur : focus, productivity et traceability.
Lire la suite de cet article »