Quelques rappels
Eclipse est un projet initié par IBM qui avait besoin de remplacer un IDE maison, Visual Age, pour passer à l'ère du java. Une de ses particularité est d'être basé sur un framework OSGI, Equinox.Ce framework offre un cadre précis pour l'ajout de fonctionnalités sous forme de services (ou modules), et le support de Java n'est qu'un module parmi d'autres. L'extensibilité est théoriquement infinie et il existe pléthore de modules et de support de langages : C++, Scala, Javascript, XML, Ruby, Ceylon...
Eclipse est même souvent rebrandé par d'autres éditeurs dans leurs produits (Adobe, IBM pour Notes, etc)
Et avec un marketplace, tout développeur peut sortir un IDE avec le support des besoins maison en quelques clics.
Mais ce qui confère à Eclipse sa force est également sa faiblesse : avec des centaines de modules disponibles, il est aisé d'obtenir au final une plateforme obèse, instable, bref inutilisable.
Et pour une équipe de développement, cela peut se chiffrer rapidement en perte de productivité, en frustration, et au final par une remise en cause des choix techniques (du vécu).
Quelques idées de bases
Pour éviter ces écueils, quelques idées de bases pour la suite de l'exercice :- La version Java IDE est la plus light et donc préférable.
- Dans le choix des modules à installer, ne prendre que le strict minimum. Tel éditeur fourni les modules core, testing, web workflow, android ? Si vous n'utiliser que les premiers, n'installer que ceux-là.
Si jamais vous faites évoluer votre projet, vous aurez suffisamment de temps pour ajouter le nécessaire, et le cycle de release de votre IDE maison devrait suivre celui d'Eclipse, qui est assez rapide. - Le marketplace d'Eclipse propose pour chaque feature un large choix des modules spécifiques, vous vous retrouvez vite avec des modules optionnels dont vous n'avez nul besoin. Preférez les required aux optionnels.
- Utiliser des bétas testeurs dans vos équipes de développement, comme tous clients, ils n'apprécient pas les produits non finis.
