jar, classpath et librairies

Version imprimable

19/07/2007, 10h10
®om

jar, classpath et librairies

Salut,

Tout d'abord, voici ce que je voudrais : une application à laquelle on puisse rajouter des librairies simplement en mettant le .jar dans le répertoire lib. En effet, l'application supportera des plugins, et les plugins auront éventuellement besoin de librairies.

Ma première idée était donc dans l'attribut "Class-Path" du manifest du jar exécutable de définir par exemple un lib/*.jar (voir ce post), ce qui apparemment n'est pas possible.

Donc il faut définir le classpath à l'exécution dans la ligne de commande.

Sauf qu'on ne connaît pas forcément à l'avance toutes les librairies utilisées (les plugins pourront éventuellement en rajouter).
Au départ je pensais qu'il n'y avait pas de problème, il suffit de faire:

Code:

java -cp .:monjar.jar:lib/*.jar monpackage.monsouspackage.MainClass

D'ailleurs j'avais testé ca fonctionne très bien (je suis sous linux)...

EDIT: en fait même sous linux s'il y a plusieurs librairies le *.jar est remplacé par "fichier1.jar fichier2.jar..." sans séparer par des ':', donc ça ne marche pas non plus... Quand j'avais testé il n'y en avait qu'une (lol)...

Mais au travail (là où je suis en stage), ils utilisent des ordinateurs avec windows, et en programmant (quelque chose qui n'avait rien à voir), je me suis aperçu que le *.jar ne fonctionnait pas en paramètre de -cp de java... (après avoir galéré 5 minutes avant de comprendre que sous dos le séparateur des répertoires est ; et non :, enfin bref).

Donc comment est-il possible de pouvoir rajouter des .jar dans le répertoire lib, qui soient reconnus à l'exécution sans changer les paramètres d'appels ni la variable d'environnement CLASSPATH, et que ça fonctionne sous toutes les plateformes (au moins Linux, Mac et Windows -PS: y'en a d'autres?-) ?

Merci d'avance
19/07/2007, 10h16
OButterlin

Le Class-Path du fichier manifest fonctionne très bien, la seule chose avec un jar, c'est qu'il ne doit pas contenir d'autres jar.
Dans ton cas, si tu copies les jar additionnels au même endroit que le jar de ton application et que tu les références dans le fichier manifest, ça fonctionnera
(Ai-je été assez clair ? ;))

A+
19/07/2007, 10h21
®om

Citation:

Envoyé par OButterlin

Le Class-Path du fichier manifest fonctionne très bien, la seule chose avec un jar, c'est qu'il ne doit pas contenir d'autres jar.
Dans ton cas, si tu copies les jar additionnels au même endroit que le jar de ton application et que tu les références dans le fichier manifest, ça fonctionnera
(Ai-je été assez clair ? ;))

A+

Oui, il marche très bien dans la mesure où tu écris le nom de tous tes .jar:

Code:

<attribute name="Class-Path" value=". ${lib.dir}/Trendy_1.8.jar ${lib.dir}/jawin.jar ${lib.dir}/xpp3_min-1.1.3.4.O.jar ${lib.dir}/xstream-1.2.1.jar" />

Mais si tu ne sais pas forcément le noms de tous les .jar (car certains peuvent être rajoutés), tu ne peux pas écrire:

Code:

<attribute name="Class-Path" value=". ${lib.dir}/**.jar" />
19/07/2007, 10h42
OButterlin

D'accord, je n'avais pas compris le fond de ton problème...
Une bidouille peut-être :aie: :
Si tout est en locale, tu pourrais passer par une fonction intermédiaire qui liste les jar et construit la commande (pour la lancer via Runtime.getRuntime().exec(...)) à moins qu'on puisse directement changer le class-path de la jvm en cours (je ne sais pas)
Je te l'accorde, c'est de la pure bouze...

Sinon, tu pourrais peut-être faire un générateur de manifest (c'est quand même mieux par ce fichier...)
19/07/2007, 10h53
®om

Citation:

Envoyé par OButterlin

Sinon, tu pourrais peut-être faire un générateur de manifest (c'est quand même mieux par ce fichier...)

L'application supportera des plugins, et certaines librairies pourront être ajoutées pour que les plugins fonctionnent.
Par exemple si on rajoute un plugin qui envoie un mail (juste pour l'exemple), il faudra rajouter javamail.jar dans le répertoire lib... et dans le classpath...
Sauf que quand on ajoute un plugin je ne veux pas qu'on ai besoin de modifier le jar (manifest) ni la ligne de commande...

Il est possible de charger des jars via un URLClassLoader.
Un truc du genre

Code:

1
2
3
4
5
6
7
8
9
10
11
public void loadJars(File[] jars) {
    URL[] urls = new URL[jars.length];
    for(int i = 0; i < jars.length; i ++) {
        try {
            urls[i] = jars[i].toURI().toURL();
        } catch(MalformedURLException ex) {
            ex.printStackTrace();
        }
    }
    ClassLoader cl = new URLClassLoader(urls, getClass().getClassLoader());
}

19/07/2007, 10h59
OButterlin

J'ai du mal à comprendre ce que tu cherches à faire...
Ton application a des plugins ok, mais à un moment donné, tu les interfaces avec ton application non ? Alors où est le problème de rajouter dans le class-path ?
Tu ne charges pas tes plugins dynamiquement quand même... si ?

Citation:
Envoyé par le y@m's
Il est possible de charger des jars via un URLClassLoader.
Un truc du genre
Code:

1 2 3 4 5 6 7 8 9 10 11 public void loadJars(File[] jars) { URL[] urls = new URL[jars.length]; for(int i = 0; i < jars.length; i ++) { try { urls[i] = jars[i].toURI().toURL(); } catch(MalformedURLException ex) { ex.printStackTrace(); } } ClassLoader cl = new URLClassLoader(urls, getClass().getClassLoader()); }
OK (c'est ce que j'utilise pour charger les .jar des plugins), mais comment tu fais pour les librairies (pour que les .jar puissent accéder aux librairies)?
Une fois que tu as récupéré un classloader des librairies, tu en fais quoi?
(le développeur du plugin ne doit pas s'en occuper)

Citation:

Envoyé par OButterlin

Tu ne charges pas tes plugins dynamiquement quand même... si ?

Bah, euh, si...

:)

19/07/2007, 11h26
le y@m's

En chargeant les jars des plugins et ceux des librairies dans le même URLClassLoader cela devrait marcher (enfin je pense, c'est à vérifier ^^).
19/07/2007, 11h33
®om

Une solution qui pourrait me convenir (je testerai ce we), c'est que les plugins déclarent dans le manifest de quelles librairies il a besoin.
Et j'ajoute ces librairies au classloader du plugin...

EDIT: ça a l'air d'être la même solution que le y@ms :)