Discussion :

[tac.p]

Bonjour à tous,

Je suis actuellement sur un projet qui contient notamment une appli contenant un serveur Jetty qui tourne dans un framework OSGi.

Mes problèmes ont commencés quand j'ai voulu installer la version Mars d'Eclipse, à cause du saut de version de Jetty (de 8 à 9 alors que les bundles de websockets de Jetty 9 ressemblent assez peu à la version précédente, et que les dépendances de bundles sont très contraintes en terme de version).
Ces problèmes ayant été résolu après pas mal d'essai, j'essaie d'écrire un process pour que mes collègues puissent faire l'upgrade vers mars et l'upgrade du projet conjointement, et là j'observe des comportements que je n'arrive pas à expliquer. En fait, j'ai beaucoup de mal à faire 2 installations identiques, d'où ces quelques questions, qui tournent autour de l'installation de bundles.


Q1. Le répertoire dropins de eclipse utilisé par p2 : Si on suit la doc du site de p2 ici, j'en comprend que le dossier dropins est scanné (et ses plugins incorporés dans le framework OSGi d'Eclipse) à chaque démarrage d'Eclipse. En pratique, j'ai observé qu'il est beaucoup plus sûr de forcer un -clean dans la ligne de commande d'Eclipse pour que cela se produise, c'est néanmoins très lourd/long. Il semble que le dossier dropins est aussi scanné lorsque Eclipse propose un redémarrage après avoir installé des plugins ou fait des mises à jour. Savez-vous quelle option correspond à ces types de redémarrage, et pouvez-vous confirmer/corriger mes observations concernant le scan du répertoire dropins ?

Q2. Plugins proposés pour les required-plugins dans le wizard des MANIFEST.MF : Quand on veut définir les required bundles d'un bundle que l'on développe, en utilisant le wizard de génération de Manifest, ce dernier propose une liste où l'on peut choisir ces bundles. De mon expérience passée, j'imaginais que cette liste était construite en joignant les bundles définis dans le workspace et ceux de la platforme OSGi dans lequel Eclipse s'execute (ceux résolus à priori). Sur au moins l'une de mes installation, le wizard ne propose pas (d'ailleurs le buildeur d'Eclipse ne reconnais pas et ne trouve pas) des bundles pourtant présent dans la plateforme OSGi dans laquelle Eclipse s'execute (je vais la vérification en exécutant un ss dans la console). Qu'est ce qui peut expliquer ceci ? Comment est construite la liste des bundles connus par Eclipse pour les développements dans le workspace ?

Q3. Faire du dévelopement de plugins avec Eclipse Java : J'essaie d'éviter l'installation d'un Eclipse JEE en me restreignant à un Eclipse Java (qui me semble suffisant). Pour les développement de plugins, je dois alors installer le Plugins Development Tools de l'Eclipse MarketPlace. Dans certain cas cela ne suffit pas. (Je ne peux pas créer de nouveaux projets de type plugins, les Manifest.MF ne peuvent pas être ouvert avec leur Wizard. Est-ce que cela n'est pourtant pas censé suffire ? Sinon que me manque-t-il que j'installe parfois sans savoir ou en ayant installé un eclipse JEE en parallèle de de l'Eclipse Java, dans ce cas c'est peut-être p2 qui me résoud des dépendances sans que je m'en sois apperçu. Un avis ?

Merci d'avance pour vos éclaircissements

Pierre

[tac.p]

Comme j'ai trouvé la réponse à la question 2, je vous en fait part...

Q2. Plugins proposés pour les required-plugins dans le wizard des MANIFEST.MF : Quand on veut définir les required bundles d'un bundle que l'on développe, en utilisant le wizard de génération de Manifest, ce dernier propose une liste où l'on peut choisir ces bundles. [...] Sur au moins l'une de mes installation, le wizard ne propose pas (d'ailleurs le buildeur d'Eclipse ne reconnais pas et ne trouve pas) des bundles pourtant présent dans la plateforme OSGi dans laquelle Eclipse s'execute (je vais la vérification en exécutant un ss dans la console). Qu'est ce qui peut expliquer ceci ? Comment est construite la liste des bundles connus par Eclipse pour les développements dans le workspace ?

Sur la machine où le problème se produisait, j'avais procédé à un update d'Eclipse sans écraser le Workspace. Il n'y avait aucune erreurs dans la console Eclipse, mais dans le fichier de log du workspace plein d'erreurs car ils n'arrivait à charger les bundles de la plateform (en fait PDE essayait de charger les bundles d'une version antérieure en faisant des install file:// pointant vers le dossier plugins d'Eclipse mais des noms de bundles d'une version antérieure).
C'était en fait une erreur sur la définition de la Target Platform utilisée par PDE (Plug-in Development Environment). Pour réparer ceci il a fallut écraser et recréer la Target Platform (chercher dans Preferences > Plug-in Development > Target Platform).

En fait tout les wizard viennent de PDE, et les relations de build sont aussi générées par PDE, j'en comprend que PDE gère lui-même une (ou plusieurs) plateforme(s) OSGi qui peut (mais n'est pas forcément) la plateforme hôte d'Eclipse dans lequel PDE s'exécute.
Ma compréhension de ce point est-elle exacte ?

Je suis toujours preneur de réponses sur les autres questions...

[Mickael_Istria]

Q2. Plugins proposés pour les required-plugins dans le wizard des MANIFEST.MF : Quand on veut définir les required bundles d'un bundle que l'on développe, en utilisant le wizard de génération de Manifest, ce dernier propose une liste où l'on peut choisir ces bundles. De mon expérience passée, j'imaginais que cette liste était construite en joignant les bundles définis dans le workspace et ceux de la platforme OSGi dans lequel Eclipse s'execute (ceux résolus à priori). Sur au moins l'une de mes installation, le wizard ne propose pas (d'ailleurs le buildeur d'Eclipse ne reconnais pas et ne trouve pas) des bundles pourtant présent dans la plateforme OSGi dans laquelle Eclipse s'execute (je vais la vérification en exécutant un ss dans la console). Qu'est ce qui peut expliquer ceci ? Comment est construite la liste des bundles connus par Eclipse pour les développements dans le workspace ?

Comme tu l'as compris ensuite, le framework OSGi et les bundles disponibles pour le developpement de plugins correspondent a la "Target Platform" que tu peux configurer dans les preferences de PDE. Cette target-platform, comme son nom l'indique, doit correspondre a l'ensemble des bundles que estime necessaire pour le developpement et l'execution de tes propres bundles, incluant en fait ton application "cible" (dans laquelle tu veux deployer tes plugins/bundles).

Q3. Faire du dévelopement de plugins avec Eclipse Java : J'essaie d'éviter l'installation d'un Eclipse JEE en me restreignant à un Eclipse Java (qui me semble suffisant). Pour les développement de plugins, je dois alors installer le Plugins Development Tools de l'Eclipse MarketPlace. Dans certain cas cela ne suffit pas. (Je ne peux pas créer de nouveaux projets de type plugins, les Manifest.MF ne peuvent pas être ouvert avec leur Wizard. Est-ce que cela n'est pourtant pas censé suffire ? Sinon que me manque-t-il que j'installe parfois sans savoir ou en ayant installé un eclipse JEE en parallèle de de l'Eclipse Java, dans ce cas c'est peut-être p2 qui me résoud des dépendances sans que je m'en sois apperçu. Un avis ?

Je te recommande d'utiliser le Eclipse RCP/RAP. RCP est grosso-modo un synonyme de developpement de plugins Eclipse.

[tac.p]

OK, Merci,

Je te recommande d'utiliser le Eclipse RCP/RAP. RCP est grosso-modo un synonyme de developpement de plugins Eclipse.

du coup je me suis fait une install eclipse RCP/RAP pour voir, j'avais jamais trop osé car on est loin d'utiliser tte l'artillerie RCP, on fait juste un serveur avec pas mal de code métier à l'intérieur, mais on ne fait pas de UI sur l'appli. On utilise OSGi pour des questions historiques au départ et la modularité et les micro-services, la distrib d'event ont fait qu'on a gardé le framework.

Cette target-platform, comme son nom l'indique, doit correspondre a l'ensemble des bundles que estime necessaire pour le developpement et l'execution de tes propres bundles, incluant en fait ton application "cible" (dans laquelle tu veux deployer tes plugins/bundles).

oui j'ai un peu essayé de configurer des targets perso pour voir quels étaient les degrés de liberté. Je m'en suis fait une juste limitée à mes besoins, et je fini par trouver cela limite redondant avec le config.ini (où l'on liste les bundles chargés dans le framework au runtime) et le .product (où l'on liste les bundles que l'on veut voire figurer dans la "target" installé pour l'exécution dans .metadata/.plugins/org.eclipse.pde.core/monappli/plugins).
Je comprend les différences (enfin je crois) mais cela devient un peu usine à Gaz [oui là je fais un peu le grincheux... mais bon je m'y suis habitué]

Au fait pas d'idée pour la question 1, forcer p2 à vérifier les bundles dans dropins sans utiliser l'arme atomique du -clean.