Java annotations et introspection-reflexion

J'étais sur le point d'écrire un article sous forme de petit cours au sujet des annotations Java jusqu'à ce que je parcoure le web et finisse par tomber sur deux documents très intéressants. Alors plutôt que faire du plagiat, je vais simplement vous diriger directement vers ces ressources, en vous expliquant tout de même pourquoi je les ai choisi particulièrement.


Conférence: Les annotations enfin expliquées simplement
: sur le blog de Zenika (une société proposant des services d'expertise dans le monde Java/Open source), un premier cours très intéressant (slides et fichiers source à l'appui) pour commencer à prendre en main le concept d'annotations et d'introspection : définitions, règles, personnalisation... C'est par ceci qu'il faut commencer si vous voulez vous lancer dans ce domaine!

Cours de Julien Cervelle : Réflexion et annotation : professeur à l'université de Marne-la-Vallée qui a rédigé un cours plus avancé et pointu sur certains aspects de la réflexion en Java : travailler avec des types paramétrés, détail du package java.lang.reflect, problématiques de sécurité et annotations. Une mine d'or!


Fichier(s) joint(s) :



e4 : enfin un IDE sexy! (même si...)

e4 est le petit nom donné à la nouvelle version de l'IDE Eclipse, encore à l'état d'incubation dans les Eclipse projects mais dont les premières releases sont déjà très prometteuses...

Avant tout, voici les premiers liens utiles pour vous renseigner à ce sujet :

  • Présentation du projet, sur la page officielle
  • Le wiki Eclipse, qui permet de prendre connaissance des différentes avancées du projet, premiers tutoriaux et documentations, télécharger les nouvelles releases...

Et maintenant, un aperçu du nouveau look :


Comme vous pouvez le voir, l'ensemble paraît beaucoup plus travaillé et stylisé. Une clarté dans la séparation des panneaux rend la prise en main un peu plus simple.

D'un point de vue purement pragmatique, le reproche que l'on peut faire à cette interface est de perdre en efficacité puisqu'elle réduit la surface utile (à cause des nouvelles formes et dispositions des vues). Mais on met alors le doigt sur un débat lancé il y a quelques mois sur l'équilibre à trouver entre efficacité et utilisabilité de l'interface.

Kevin McGuire a écrit plusieurs articles à ce sujet, décrivant comment l'interface actuelle d'Eclipse "gaspille" réellement certains espaces : Eclipse UI Real Estate Wasters!. Il propose également quelques solutions pour améliorer cette ergonomie : Every pixel is sacred (not any more!).

Enfin, Michael Scharf propose quant à lui un moyen de passer l'IDE en fullscreen afin de remédier à ces inconvénients : Every pixel counts! The new eclipse fullscreen plugin.... Mais comme vous pourrez le constater, ces discussions datent d'un moment et il ne me semble pas que tout ceci ait réellement avancé depuis... Alors peut-être y a-t-il de nouvelles choses à exploiter avec les nouvelles versions de l'IDE!


Fichier(s) joint(s) :



Planet Eclipse et la communauté francaise

Il y a peu de temps, j'ai voulu m'inscrire au sein de la communauté Eclipse Planet afin de figurer parmi les nombreux membres actifs... Suivant la démarche indiquée, j'ouvre un post dans le bugzilla d'Eclipse. La réponse ne s'est pas faite attendre, mais mauvaise nouvelle : ils n'acceptent pour l'instant que les blogs publiant des posts en anglais. Loin de moi l'idée de critiquer ce concept, mais le but de mon blog est justement de promouvoir et supporter la communauté française.

Voici le lien vers le ticket en cours : Bug 325703. Comme vous pourrez le constater, la personne qui m'a répondu indique qu'ils envisagent de bientôt prendre en compte toutes les langues! Alors patience et persévérance!


Fichier(s) joint(s) :



Communauté officielle des développeurs Eclipse

Une fois de plus, au hasard de mes déambulations sur la Toile, je suis tombé sur un lien que je souhaite partager : le site Planet Eclipse qui rescence un grande quantité de liens vers des bloggers/développeurs Eclipse. En somme, une base de connaissance sans fin! Le détour en vaut la peine...


Fichier(s) joint(s) :

Retrouver les icônes utilisés dans Eclipse

Je fais suivre un lien intéressant sur lequel je viens de tomber un peu par hasard, sur le blog de Benjamin Cabé, qui permet de récupérer tous les icônes utilisés dans l'IHM d'Eclipse Ganymede. Cela peut être intéressant pour reproduire des interfaces COTS ;) : les icônes ici


Fichier(s) joint(s) :



Maîtriser Tycho de A à Z - part 4

Nous allons voir ici comment créer d'une part un référentiel pour le build Tycho, plutôt que d'utiliser la plateforme cible définie précédemment, et d'autre part comment mettre en place un site de mise à jour pour une application RCP.

Plateforme implicite

Nous avons vu dans le précédent article comment utiliser une plateforme cible pour déployer une application avec Tycho. L'intérêt de ce chapitre est de démontrer la possibilité de déposer les plugins nécessaires au déploiement sur un référentiel Eclipse, tout comme le référentiel Galileo par exemple.

La première étape est de construire le référentiel. Dans Eclipse, il faut exporter les features utilisées dans le projet, en spécifiant bien de générer les metadata.

Ensuite, il faut placer ce répertoire sur un serveur qui sera accessible par Tycho (par exemple sur un Apache simple : http://localhost/tychoRepository)

Finalement, il ne reste plus qu'à compléter le POM global du projet en ajouter l'instruction :


 
  developpef
  http://localhost/tychoRepository
  p2
 

Le build peut donc simplement être lancé par la commande : mvn clean package. Tycho ira automatique chercher les plugins de l'application sur le référentiel distant, tout comme il le fait vers le référentiel central pour ses plugins de base.

Création du site de mise à jour

Ici, rien de compliqué. Il faut commencer par créer, dans Eclipse, un projet de site de mise à jour (avec l'assistant adéquat). Le projet en question ne contient qu'un fichier site.xml dont le seul but est de rescencer les feature qui devront faire l'objet de mises à jour. Nous allons donc y ajouter com.developpef.rcpfeature :

Il faut maintenant relancer la génération des fichiers POM sur le workspace pour voir apparaitre, dans le projet en cours, un fichier généré comportant le packaging-type "eclipse-update-site". Il suffit alors de lancer la commande citée plus haut pour que Tycho construise, dans le dossier "target" du projet, un site de mise à jour de type p2 (l'action "Build All" d'Eclipse aura le même résultat).

A propos du packaging type "eclipse-update-site"

Comme indiqué dans cet article de Git, ce packaging type utilisé aujourd'hui par Tycho (v0.9.0) fait référence à l'ancienne version de référentiel p2 d'Eclipse, qui n'a pas la structure désirée. Il ne pourra donc pas être déployé par la simple commande mvn deploy mais plutôt à la main ou grâce à une tâche Ant par exemple.


Fichier(s) joint(s) :



Maîtriser Tycho de A à Z - part 3

Aujourd'hui nous allons nous attaquer à la mise en place du build headless et lancer Tycho pour la première fois!

Pour qu'une application puisse être construite entièrement en dehors d'un environnement PDE, il faut rajouter à la plateforme cible que nous avons construit précédemment les plugins nécessaires à la création des launchers (exécutables). Pour ceci, il faut récupérer un Delta pack, comme celui que vous pourrez trouver ici, qui contient tout ce dont nous avons besoin.

Pour l'intégrer à notre projet, voici la démarche à suivre :

  • Téléchargez le pack et décompressez le dans le dossier de la plateforme cible afin d'y ajouter tout son contenu.
  • Dans Eclipse, rechargez le fichier .target pour actualiser la liste des plugins/features disponibles.
  • Importez dans le workspace la feature org.eclipse.equinox.executable (pas en tant que "binary project") afin de pouvoir l'épurer des plugins non nécessaires à votre configuration (selon l'environnement d'exécution de l'application)
  • Ajouter la feature à celle utilisée par notre produit (ici com.developpef.rcpfeature)
  • Re-générer les fichiers POM de Tycho afin que la feature soit ajoutée aux modules utilisés.

Et voilà, cette fois-ci notre plateforme cible est prête pour être utilisée avec Tycho!

Et pour ce faire, rien de plus simple : placez-vous à la racine du workspace et lancer la commande mvn clean package -Dtycho.targetPlatform=C:\minimal_target

Comme à son habitude, Maven va télécharger la terre entière dans son repository et au début du moins, le build risque d'être en échec suite au manque de quelques plugins nécessaires à Tycho. Il vous suffit de les récupérer depuis une intallation classique d'Eclipse et tout devrait rouler!


Fichier(s) joint(s) :



Maîtriser Tycho de A à Z - part 2

Ce deuxième article de la série a pour but d'illustrer comment configurer les fichiers POM du projet qui seront utilisés pour le build Maven.

Génération des fichiers POM

Tycho dispose d'une tâche qui permet de générer les fichiers POM de chaque projet. Pour ce faire, se placer au niveau du workspace Eclipse et lancer la commande :

mvn org.sonatype.tycho:maven-tycho-plugin:generate-poms -DgroupId=com.developpef

Le plugin Tycho est tout d'abord téléchargé et une fois le processus terminé, on pourra trouver :

  • à la racine du workspace, un fichier POM contenant des liens vers tous les projets (« modules »).
  • un fichier POM dans chaque projet indiquant sa nature (eclipse-plugin, eclipse-feature...)

Configuration du POM principal

Afin d'assurer le bon déroulement du build Tycho, le fichier POM situé à la racine du worskpace doit être configuré de la manière suivante :

  • ajouter l'option permettant de forcer l'utilisation du compilateur Java 6 (pour la prise en charge des annotations) :
    
    
    
    
    org.sonatype.tycho
    maven-osgi-compiler-plugin
    true
    0.9.0
    
    6.0
    6.0
    
    
    
    
    
  • paramétrer l'environnement d'exécution cible du produit. Par exemple :
    
    org.sonatype.tycho
    target-platform-configuration
    0.9.0
    
    
    
    win32
    win32
    x86
    
    
    p2
    
    
    

Cette configuration devrait permettre de faire fonctionner la plupart des projets Java 6 de base.

Dans le prochain article, nous verrons comment compléter la plateforme cible pour réaliser un véritable build "headless" puis lancer notre premier build Tycho.


Fichier(s) joint(s) :

Maîtriser Tycho de A à Z - part 1

Ce premier article décrit comment créer un produit indépendant de l'interface de développement PDE.

Configuration du produit

Afin que Tycho résolve correctement les liens entre le produit et les autres projets, il est indispensable de créer un projet propre au produit, qui ne contiendra rien d'autre. Le projet "com.developpef" contient donc uniquement le fichier "com.developpef.product" (pour Tycho, le fichier doit porter le même nom que le projet, suffixé par ".product"). Il est également important que la configuration du produit se base sur des features et non des plugins. Voici la configuration terminée :

Création de la plateforme cible

L'intérêt de créer une plateforme cible est de permettre à l'application finale (le produit) de se lancer depuis un ensemble minimal de plugins que nous aurons défini qui sera au final utilisé comme base pour le build automatique de Tycho.

Commençons par créer la feature de base de notre produit qui contiendra ces fameux plugins de base. A l'aide de l'assistant de création de projet, créons un projet de feature. Elle devra être initialisée à partir d'une application RCP standard, comme illustré:

Une fois la feature créée, on pourra voir dans sa liste de plugins tout ce qui concerne une application Eclipse de base. Il faut cependant l'épurer de ce qui reste encore inutile (plugins pde...) : pour ce faire, il faut exporter la feature dans un répertoire quelconque (disons C:\minimal_target) puis supprimer tous les plugins contenant : source, mylyn, wst et pde.

Pour terminer, nous allons créer la définition de la cible. Dans un nouveau projet, créer une nouvelle "target definition", puis dans la catégorie "Location", renseigner le dossier généré précédemment :

Pour terminer, cliquer sur le lien "Set as target platform" pour indiquer au workspace de se baser uniquement sur les plugins et features de ce dossier pour compiler l'application.

Dans le prochain article, je décrirai comment utiliser Tycho pour générer les fichiers POM nécessaires à la description des projets pour la compilation de Maven.


Fichier(s) joint(s) :

Maîtriser Tycho de A à Z

Le but de cette série d'articles est d'aider à la mise en place de Tycho et à l'automatisation du déploiement de plugins Eclipse.

Je décrirai le processus complet depuis la création des projets Eclipse jusqu'à la mise en place dans un système d'intégration continue.

Voici donc la liste des articles sur ce sujet (en cours de rédaction) :

  1. Mise en place des projets Eclipse
  2. Génération des POM de base
  3. Plateforme cible complète et premier build
  4. Mise en place des référentiels : pour le build Tycho et la mise à jour de l'application finale

Fichier(s) joint(s) :