Eclipse-BuddyPolicy: registered et Eclipse-RegisterBuddy: com.provider.team.project

Eclipse-BuddyPolicy: registered et Eclipse-RegisterBuddy: com.provider.team.project

Aie cet article commence directement par des insanités de configuration... On va tenter d'expliquer tout ça !

Le but étant de répondre à la question : comment configurer les plugins eclipse pour permettre à un plugin d'accéder aux "classpath" d'un autre plugin qui est dépendant du premier plugin.

Si vous avez un plugin 1 et un plugin 2 avec le plugin 1 qui dépend du plugin 2 et par exemple un accès aux ressources du plugin 1 par le plugin 2... oui oui c'est incompréhensible mais c'est possible comme situation !

Par exemple, en ce qui concerne la gestion des fichiers ressources. Vous avez une classe Bundle1 dans le plugin 1 qui se charge d'accéder au fichier bundle1.properties se trouvant aussi dans plugin 1. Cette classe étend AbstractBundle dans le plugin 2 qui est un facilitant pour coder des classes d'accès aux fichiers ressources. Toutes les méthodes d'accès au fichier de ressource se trouvent dans AbstractBundle et pourtant le plugin 2 n'a pas accès aux ressources du plugin 1 car la dépendance va dans l'autre sens... Et donc pendant l'exécution vous avez des erreurs types filenotfound ou autre.

On peut aussi très bien avoir le même problème pour des accès à des classes à la place des fichiers ressources et le problème est le même. Un plugin ne sait pas accéder au classpath des plugins qui dépendent de lui, il faut le configurer pour cela.

Dans ce cas précis, il faut spécifier au plugin 1 quels sont les plugins qui sont autorisés en ajoutant dans son MANIFEST.MF la ligne suivante:

Eclipse-RegisterBuddy: com.provider.team.plugin2

Avec com.provider.team.plugin2 qui correspond à l'ID du plugin 2.

Puis dans le MANIFEST.MF du plugin 2 il faut spécifier la politique de gestion du classloading en ajoutant la ligne:

Eclipse-BuddyPolicy: registered

Ce qui signifie que seuls les plugins s'enregistrant comme autorisant le plugin 2 à accéder à leur classpath seront accessibles par le plugin 2... Ouf !

Certains diront qu'il suffit de mettre une dépendance du plugin 2 vers le plugin1 pour résoudre le problème mais les dépendances cycliques ne sont pas recommandées et surtout ce n'est pas forcément possible car le plugin 2 peut très bien être un plugin de type framework/utilitaire (log4j, spring, hibernate etc...) et on ne va pas modifier une plugin de ce type pour lui spécifier tous les plugins auxquels il peut accéder.

Références:
http://wiki.improve.fr/wiki/moni/trucs
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html
http://www.ibm.com/developerworks/library/os-ecl-osgi/index.html (Buddy class loader options)
et Google :D

(partie 2) Intégration de Maven dans un projet Java J2EE Hibernate/Spring/Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même !

Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même ! (partie 2)

Voici la suite de l'article concernant l'utilisation de Maven avec WTP d'Eclipse.

Le but étant de trouver une solution pour utiliser à la fois Maven et ainsi bénéficier de l'avantage de la gestion de la configuration des dépendances tout en restant WTP "compliant" et ainsi être capable de debugger le serveur dans l'environnement Eclipse.

En fait c'est assez simple, vous prenez votre projet "assembly" maven, celui qui vous permet via maven de générer votre archive web, votre war par exemple et vous exécutez la commande suivante dans son répertoire :

mvn -Dwtpversion=1.0 eclipse:eclipse

Bien entendu vous remplacez "1.0" par R7, 1.5 ou 2.0 en fonction de votre version WTP.

Après ça, un répertoire .settings va être créé à la racine du projet avec un fichier ".component" dans notre cas (version 1.0). Dans ce fichier on va retrouver toutes les dépendances du projet que ce soit les librairies ou les projets dont il dépend. Toutes les dépendances apparaissent sous forme de jars situés dans le dépôt maven.

Problème: en mettant les projets dépendants via leur archive jar sous maven, il n'est pas possible de les modifier en debug sous eclipse. Il faut supprimer les références vers les projets dépendants dans le fichier ".component" pour ne laisser que les librairies utilisées. Ensuite il faut faire un clic droit sur le projet et sélectionner "properties" puis dans la fenêtre qui apparaît il faut cliquer sur "modules dependencies". La prochaine fenêtre permet de sélectionner les projets dépendants, il faut alors cocher tous les projets que vous avez supprimé du fichier .component à l'étape précédente et terminer en validant en cliquant sur OK.

Après quoi il faut vérifier que le fichier .component contient bien les nouvelles dépendances vers les projets fraîchement supprimés puis ajoutés, mais cette fois avec des dépendances de type module ! (et non jar)

Après quoi, il faut ajouter un serveur à WTP si ce n'est pas déjà fait puis ajouter le projet ainsi modifié au serveur WTP... puis le lancer, mettre des points d'arrêts et s'y rendre, modifier le code source "en live", sauvegarder la classe modifiée et prendre soin de builder via eclipse (Ctrl + B ou build auto) et là: contempler le debugger d'Eclipse continuer de debugger normalement.

En fait il n'y a rien de magique dans tout ça, c'est simplement un projet assembly Maven auquel on ajoute la fonctionnalité WTP permettant de debugger... Cette solution à un inconvénient MAJEUR !!! La maintenabilité !!! A chaque dépendance maven ajoutée qu'elle soit de type librairie ou projet... il faudra l'ajouter manuellement (via clic droit properties modules dependencies...)

Je compte me pencher sur ce point ASAP... des pistes ? utiliser WTP 2, tester le nouveau plugin eclipse pour maven, utiliser un script de synchronisation, réécrire WTP... etc...

Wazaabi & Eclipse RCP

Eclipse RCP, un environnement de développement "utopique" :

Un des besoins récurrents chez les clients de type grand compte est de refondre leurs applicatifs métier réalisés avec des technos archaïques. Les raisons qui poussent les clients à refaire ce type d'application sont l'arrivée de nouveaux besoins, la nécessité d'interfacer les applicatifs, permettre une meilleure maintenabilité, augmenter l'ergonomie et j'en passe. Pour ce faire, une des solutions permettant de répondre tous les besoins est d'utiliser le framework d'Eclipse RCP ! Ce n'est pas la seule solution mais elle mérite d'être mise en avant son potentiel est intéressant.

Eclipse RCP permet très facilement de générer des applications clientes qui sont capables de communiquer avec un serveur distant. Avec des interfaces graphiques basées sur des composants propres au système d'exploitation exécutant, Eclipse RCP possède un véritable tookit de widgets standardisé, comme son nom l'indique (SWT = Standart Widget Toolkit). Accompagné de JFace, une surcouche à SWT, Eclipse RCP se dote d'un cadre de développement simple pour les composants dits "complexes" (les listes par exemple) mais c'est aussi une foultitude de fonctionnalités complémentaires: boites de dialogues, assistants, raccourcis clavier, undo/redo, filtres/tris... SWT s'occupe donc de fournir une bibliothèque de composants performants alors que JFace permet de simplifier la création des interfaces et offre un cadre de développement ainsi que des facilitant puissants !

Eclipse RCP c'est aussi et surtout le workbench d'Eclipse: ses vues, ses éditeurs, sa gestion des perspectives et ses fenêtres de préférence... Un atout considérable pour créer une application complexe ! Un environnement de travail ou les aspects principaux de l'application sont régis par des règles répondant à des besoins basiques. Ce framework, c'est aussi la gestion des plugins dont hérite une application de type Eclipse RCP, ce qui permet d'étendre des plugins existants ou de laisser la possibilité à d'autres d'utiliser son application, son plugin pardon...

Bien sur en choisissant Eclipse RCP, on prend ce qu'il y a de meilleur, c'est a dire l'environnement de développement d'Eclipse, l'IDE Java le plus aboutit à mon sens dont les performances et la maniabilité n'est plus a démontrer ! C'est notamment un facilitant de création pour les plugins Eclipse (RCP ou non) ou encore un assistant pour dessiner ses interfaces graphiques avec Visual Editor ! Utiliser Eclipse RCP c'est aussi "s'assurer" une compatibilité avec la batteries de projets Eclipse tel que BIRT, GEF etc...

Parlons de Wazaabi, un facilitant pour Eclipse RCP :

Je n'ai pas parlé des inconvénients d'Eclipse RCP... oui, comme tout ce qui existe, il y existe des inconvénients propres à Eclipse RCP ! Et la conception des interfaces graphiques en fait partie... En effet, un des avantages des applications web sur les clients riches type Eclipse RCP, est de pouvoir concevoir les écrans via un langages balisé comme l'HTML. Wazaabi est la pour combler ce manque ! Il permet de créer des interfaces graphiques en utilisant le langages XUL très proche du XML. Les fichiers XUL comme les fichiers HTML sont interprétés par un moteur de rendus pour générer visuellement les écrans ! Ceci permet de séparer la conception des écrans et les services métiers de l'application comme pour les clients légers en somme.

Pour résumer Wazaabi est une surcouche à Eclipse RCP qui est une alternative à l'utilisation de Visual Editor pour concevoir ses écrans. Ce framework permet notamment de mettre facilement en place l'internalisation des écrans depuis peu, et bientôt les feuilles de style. De plus, d'ici quelques temps un éditeur graphique permettra bientôt de concevoir les interfaces graphiques XUL... ce qui est tout de même un manque pour un facilitant dans ce même domaine mais passons... Un projet plein d'avenir qui a déjà été utilisé chez Leroy Merlin ainsi que chez Kiabi sur divers projets sur lesquels j'ai eu la chance de pouvoir m'impliquer.