Développement d'un logiciel orienté plug-in : Quelle techno ? OSGi ? JPF ? [Résolu]

[Titi41]

Bonjour,

Je souhaite développer une application basée sur des plug-in.
Ce sera une base à laquelle se grefferai des plug-in pour ajouter/enlever des fonctionnalités ou même modifier des formulaires.

Je ne sais pas vers quoi me tourner.
JPF : J'ai l'impression que ce n'est plus tenu à jour. Judicieux de partir sur une technologie plus supportée ?
OSGi : Ce que j'ai le plus en vue. Mais j'ai lu que c'était dur à mettre en place. Et que la conception devrait être adaptée. Mais dans quel sens ? Je ne trouve pas de documentation répondant à mes interrogations.
Java Plug-in technology : J'ai l'impression que c'est uniquement pour le développement web, avec des applets.
SPI : Pareil, est-ce toujours supporté ?

Est-ce que j'oublie des Framework ?
Je en sais pas trop quoi penser... Comme ce concept de plug-in est nouveau pour moi, je n'ai pas beaucoup de recul et de connaissances.

Donc si quelqu'un pouvait m'apporter un regard extérieur et connaisseur, ce serait super !
Merci d'avance

[verbose]

Je te recommande vivement OSGI qui est de très loin la solution la plus réputée. Je l'ai utilisé il y a quelques temps, je ne me rappelle plus trop, mais je n'ai rencontré aucune difficulté à la mise en oeuvre.

A l'époque, j'avais suivi ce tuto : http://t-templier.developpez.com/tut...va/osgi/osgi1/

Bon courage

[Nemek]

+1 pour OSGi

Très simple et rapide à mettre en place.
Là où je bosse nous utilisons l'implémentation Apache Felix.

Le seul effort de conception à faire est de bien penser ton système en terme de plug-in. Ce qui n'est en rien spécifique à OSGi mais bien à ta problématique.
Dans OSGi tu as tout un cycle de vie, un système de listener et de requêtage pour gérer ça simplement.
Il faut bien garder à l'esprit qu'un bundle (module OSGi) peut disparaître à tout moment et qu'il faut constamment "checker" l'état du module avant de l'utilisater ou l'appeler.
Il faut donc bien nettoyer les références partagées en cas d'erreur d'un module, ne pas trop dépendre de classe mais plutôt d'interface, etc.

Je distingue deux forme d'utilisation OSGi

1. Le mode "plateforme" : tu lances un main générique qui démarre le framework qui démarre automatiquement et/ou à la demande des modules. Utile si tu n'as pas de tronc "commun" fort entre les modules.
2. Le mode "embarqué" (cas typique d'un système de plug-in) : ton application définit une API qui est partagé par tes plug-ins. C'est l'application qui configure et démarre le framework. C'est donc l'application qui a le contrôle sur la gestion des modules. Elle peut arrêter / démarrer les modules sur la base de règles fonctionnelles / action utilisateurs.

[Titi41]

Merci pour vos deux retours.

Je vais donc me diriger vers OSGi.

Mon application ressemble plus au deuxième cas que tu as mis en avant, Nemek.

J'attaque bientôt les dev. J’espère ne pas avoir trop de problèmes !

[professeur shadoko]

parent pauvre (mais propre sur soi) java.util.ServiceLoader
facile à utiliser pour des greffons sur des services simples définis par des interfaces . Bien pour commencer à s'habituer (pas la richesse d'OSGI)

[Nemek]

Interressant je ne connaissais pas.
Ayant un peu la flemme de potasser, j'aurai quelques questions:

1. Peut-on avoir plusieurs fichier META-INF/services/com.developpez.MaClasse ?
2. Le(s) fichier(s) est(sont)-il(s) rechargé(s) à chaque appel à la méthode "load" ?

[Titi41]

OK, je vais étudier aussi ServiceLoader pour le début.
Merci