Discussion :

[dfg]

Bonjour,

Après maintes recherches sur le forum et sur internet, je me permets d'exposer mon problème ici:

Je développe un plugin eclipse qui a besoin d'un paquets de .jar externes (l'api pellet).

Je voudrais importer les classes de ces .jar au moment de l'exécution.

Cela fonctionne en spécifiant statiquement le chemin (interne au projet) des .jar dans la directive Bundle-ClassPath du MANIFEST.MF (via le plugin editor).

Mais je voudrais importer les classes dynamiquement pour que l'utilisateur puisse spécifier dans les préférences le chemin de l'api pellet.

J'utilise pour cela un UrlClassLoader qui importe bien mes classes (je vois ça en mettant -verbose:class en argument de la VM).

Cependant rien n'y fait : j'ai une NoClassDefFoundError dès que je veux utiliser une classe importée dynamiquement.

Voilà comment je procède :

Je charge le .jar dans un URLClassLoader et je charge les classes qu'il me faut

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
URL url = new URL("jar:file:///chemin/vers/mon.jar!/");
URL [] uarray = {url};
URLClassLoader ucl = new URLClassLoader(uarray);
ucl.loadClass("nom.complet.de.MaClass");
/*et plein d'autres classes*/

Ensuite je crée un objet (un thread) qui va avoir besoin de ces classes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MonThread mt = new MonThread();
mt.start() //car c'est un thread

Ensuite j'appelle ma classe importée depuis cet objet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse mc = new MaClasse()

Sachant que j'ai une directive import de MaClass pour que ça compile.


J'ai l'erreur NoClassDefFoundError à la création de MonThread, c'est à dire avant même que l'objet MonThread n'essaye d'instancier la classe importée dynamiquement.

J'ai essayé de créer le ClassLoader dans le constructeur de MonThread, même problème.


Est-ce que j'ai même le droit d'instancier la classe importée sans utiliser newInstance() ?


Si quelqu'un pouvait me donner des indications, merci.

[djo.mos]

Salut,
Si j'ai bien compris, tu es dans un environnement OSGi ? Je veux dire tu veux utiliser la classe que tu as importé dynamiquement dans un plugin ? Ca m'a l'air difficile voir dangereux à essayer de faire dans un tel environnement : on joue pas avec les classLoaders dans un conteneur OSGi

Et je comprends pa sun truc : comment arrives tu à faire :

MaClasse mc = new MaClasse()

Et faire passer ça à la compilation alors que tu n'auras accès au jar qui définit MaClasse qu'au runtime ?

[dfg]

Salut,
Si j'ai bien compris, tu es dans un environnement OSGi ? Je veux dire tu veux utiliser la classe que tu as importé dynamiquement dans un plugin ?

Oui c'est exactement ce que je veux faire.
Je ne connais pas le sens exact de environnement OSGi, mais c'est certainement le cas. Je suis sous eclipse 3.4.2 avec java 1.5. Entre autres, j'ai une classe Activator pour mon plugin et j'ai accès à une classe statique Platform pour accéder à la configuration du plugin.

Ca m'a l'air difficile voir dangereux à essayer de faire dans un tel environnement : on joue pas avec les classLoaders dans un conteneur OSGi

Pourquoi ?
Je crois comprendre que l'environnement OSGi empêche d'accéder aux .jar externes au plugin, mais l'api que je dois utiliser pèse dans les 20Mo vs 60Ko pour mon plugin, donc j'aurais voulu pouvoir distribuer le plugin nu et demander à l'utilisateur de spécifier le chemin de l'api.

Et je comprends pa sun truc : comment arrives tu à faire :

Et faire passer ça à la compilation alors que tu n'auras accès au jar qui définit MaClasse qu'au runtime ?

J'y ai accès à la compilation en mettant les jars dans le buildpath du projet. De toute façon s'ils sont dans le classpath run time (sans bidouille dynamique), ils ont besoin aussi d'être dans le buildpath pour compiler.

Je sens qu'il va falloir que j'accepte de distribuer le plugin lourd avec les jars en interne...

[blackwizard]

si tu as possibilité d'intervenir sur ton gros jar,
pour le convertir en plugin: dans les fait, ça va juste ajouter un manifest.

Cette situation est très similaire à un problème que j'ai: la gestion des dépendances Maven. Les jar sont dans le classpath, donc ça compile, mais vu qu'ils sont externes, il n'y a plus personne au runtime
J'ai du mal à trouver des info pour savoir si il y a eu des avancées sur le sujet récemment. Alors si quelqu'un à ça sous la main.

[dfg]

si tu as possibilité d'intervenir sur ton gros jar,
pour le convertir en plugin: dans les fait, ça va juste ajouter un manifest.

Le problème c'est que modifier le gros jar (en fait il y en a plusieurs) implique de le distribuer en version modifiée, or la question est justement d'éviter cela pour avoir un plugin léger.

Cette situation est très similaire à un problème que j'ai: la gestion des dépendances Maven. Les jar sont dans le classpath, donc ça compile, mais vu qu'ils sont externes, il n'y a plus personne au runtime
J'ai du mal à trouver des info pour savoir si il y a eu des avancées sur le sujet récemment. Alors si quelqu'un à ça sous la main.

Après test, le problème n'est pas vraiment le fait que le jar soit externe au plugin, car on peut spécifier dans Bundle-Classpath des fichiers en dehors de l'arborescence du plugin (avec des ../). Le problème est de ne pas connaitre l'emplacement du jar à inclure avant création du MANIFEST.MF.

Ce qui me pousse à la question de savoir s'il est possible de modifier le MANIFEST du plugin par le plugin lui-même, pour ensuite redémarrer le plugin (relancer eclipse) avec les bons réglages. Par contre il faudrait convertir les chemins absolus des jar en chemins relatifs au plugin avant de les écrire dans le MANIFEST.

Je ne sais pas si cette idée est bonne ou mauvaise. C'est peut être contre la philosophie du MANIFEST ?