Patrick Paulin a écrit à la fin de l’année 2012 une série d’articles intitulés «Eclipse RCP Best Practice» . Il est toujours bon de se (re)plonger dans ces concepts fondamentaux.
1. Introduction
Article d’introduction de la série.
2. Know where to get help
Quelques références / sites pour trouver de l’aide.
3. Use RCP for the right reasons
Retour sur les points forts de la plateforme RCP.
4. Use the correct version of RCP
Description et comparaison des deux versions actuelles «branche 3.x» et «branche 4.x» (avec notamment la liste de toutes les fonctionnalités manquantes dans la nouvelle version). Si l’IDE Eclipse Juno se fonde sur la version 4.2 (avec une livraison parallèle discrète d’une version 3.8), le moins que l’on puisse dire, c’est que cette nouvelle version n’est pas encore tout à fait mature en terme de fonctionnalités.
5. Use the correct tools
Retour sur les outils complémentaires nécessaires au développement d’application (Eclipse, WindowBuilder, Tycho, Git, Hudson…)
6. Set up a target platform
Explication de la target platform (un fichier *.target) peremettant de définir quelle sera la version d’Eclipse embarqué dans l’application RCP (cette version peut être différente de celle de l’IDE avec lequel l’application est développée).
7. Mirror Eclipse repositories
Astuce pour reproduire en local le repository d’Eclipse et ses différents plugin. Ainsi la compilation est accélérée, car il n’est pas nécessaire de télécharger les artefacts depuis les serveurs de la fondation Eclipse.
8. Create a product configuration
Explication du fichier *.product et de sa tache (build et run). C’est un outil à utiliser pour tout projet d’envergure développé au sein d’une équipe.
9. Define products with feature based dependencies
Utilisation des références de features (des groupes de plugins) plutôt qu’une grande liste de plugins dans le fichier *.product. Cela permet de ne pas avoir à s’occuper des dépendances internes des différents plugins nécessaires.
10. Remove versions from product dependencies
Astuce consistant à ne pas indiquer les numéros de version dans le fichier *.product. Ces numéros de version sont ajoutés par l’IDE automatiquement, mais souvent ce n’est pas l’intention du développeur. Il ne veut pas cette version précise, mais la dernière version stable disponible.
11. Always run code using a product configuration
Retour sur le fait qu’il est possible d’utiliser son fichier *.product pour lancer l’application plutôt qu’une launch config dans Eclipse.
12. Get your product building right away
Il est important de créer un bon build pour compiler son projet. Description de l’organisation des fichiers et des projets pour pouvoir utiliser maven et tycho sur son projet.