[JAR]définir classpath interne

Bonjour à tous,

Je voudrais savoir s'il est possible d'inclure des lib jar dans un jar afin de ne pas se 'trainer' plusieurs fichiers ?

Je m'explique, j'ai développé une application qui nécessite pas mal de librairies. Je voudrais ensuite pouvoir exécuter cette appli de façon classique, c.à.d:

java -cp ? -jar monappli.jar

L'inconnue : '?' le classpath ! Est-ce qu'il est possible de fixer le classpath dans l'appli et donner les chemins d'accès des différentes lib ?

La création du jar ne me pose pas de pb, je le crée avec ant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<jar destfile="monappli.jar"> <manifest> <attribute name="Main-Class" value="com.pkg1.pkg2.MainFrame"/> <attribute name="Version" value="0.0.0.1-beta"/> <attribute name="Built-By" value="cpr0"/> </manifest> <fileset dir="build" includes="**/*.class"/> <fileset dir="." includes="etc/res/**/*.*"/> <fileset dir="." includes="etc/dist/lib/*.jar"/> </jar>

---

Structure du jar monappli.jar créé :

/com/pkg1/pkg2/*.class (les classes de l'appli)
/etc/res/img/*.jpg (les icones/images de l'appli)
/etc/dist/lib/*jar (les lib, ex. activation.jar)
/META-INF/MANIFEST.MF (indique entre autre la Main-Class)

Par avance merci,

-David-

Citation:

---

Envoyé par cpr0

Je voudrais savoir s'il est possible d'inclure des lib jar dans un jar afin de ne pas se 'trainer' plusieurs fichiers ?

---

Oui, c'est possible (un jar n'est jamais rien qu'un zip). Masi c'est pas conseillé (pour des problèmes de montée de version et tout ce qui va avec).

Citation:

---

Envoyé par cpr0

java -cp ? -jar monappli.jar

L'inconnue : '?' le classpath ! Est-ce qu'il est possible de fixer le classpath dans l'appli et donner les chemins d'accès des différentes lib ?

---

Regarde Commons-launcher c'est justement fait pour ça :)

Bonne chance :wink:

Merci Denis, je vais regarder cela...
Je laisse encore un peu le post, je mettrai 'résolu' un peu plus tard

L'option -jar annule l'option -cp, si je ne me trompe pas.
Le classpath doit etre défini dans le Manifest du jar.

Salut,

Citation:

---

Envoyé par xavlours

L'option -jar annule l'option -cp, si je ne me trompe pas.
Le classpath doit etre défini dans le Manifest du jar.

---

En effet l'option -jar annule -cp ET la variable d'environnement CLASSPATH...

Seul le jar et les chemins défini dans la valeur Class-Path du Manifest sont utilisé comme classpath...

Une solution serait donc de ne pas intégré les librairies externes dans ton jar, mais de les placer par exemple dans un répertoire lib à coté de ton Jar. Il te suffit de rajouter ensuite dans ton Manifest la ligne :

Code:

---

Class-Path: lib/archive1.jar lib/archive2.jar

---

Le problème c'est que la tâche Ant <manifest> ne gère pas vraiment cette propriété et qu'il faut l'écrire à la main...


Mais tu peux toujours utiliser la tâche non-standard <manifestclasspath> :
http://jakarta.apache.org/hivemind/hivemind/ant/ManifestClassPath.html



Sinon si tu veux quand insérer les archives dans ton jar (perso je ne te le conseille pas), il te faut utiliser la classe URLClassLoader pour les charger...


a++

Citation:

---

Une solution serait donc de ne pas intégré les librairies externes dans ton jar, mais de les placer par exemple dans un répertoire lib à coté de ton Jar

---

oui, je n'ai pas de soucis avec ça, merci adiGuba. Pour le manifest, si tu regarde dans mon 1er post, j'utilise <manifest> de ant et cela fonctionne très bien. Si je jète un oeil dans le fichier créé, mes attributs son bin là.

Merci à tous ;)

Salut,

Citation:

---

Envoyé par cpr0

Pour le manifest, si tu regarde dans mon 1er post, j'utilise <manifest> de ant et cela fonctionne très bien. Si je jète un oeil dans le fichier créé, mes attributs son bin là.

---

Ce que je voulais dire c'est que tu dois écrire toi-même l'attribut Class-Path avec les bons éléments, du style :

Code:

---

<attribute name="Built-By" value="lib/archive1.jar lib/archive2.jar"/>

---

alors que la balise que j'ai cité permet d'automatiser cela un peu plus en utilisant les balise <classpath> standard de ant...

a++

Le but final de tout cela est de créer un exécutable. J'ai fait des tests avec JSmooth, ce n'est pas trop mal, seulement j'ai toujours ce soucis des libraries (jar) qu'il faut embarquer avec l'application !

Mon application a besoin de ces lib, n'y a t'il aucun moyen pour tout encapsuler dans un exécutable ???

J'ai tenté autre chose, j'ai récupéré les .class requis des différentes lib (.jar) que j'ai inclus dans mon application monappli.jar. Le soucis est que les autres librairies, par exemple activation, nécessitent leur propre manifest ! Il faudrait alors que j'ai un manifest partagé par les différents jar.

Quand je lance l'appli avec java -jar, il trouve toutes les classes dont il a besoin, logique, mais il lui manque certains manifests !!!

Je vais revenir à ce procédédé (récup et inclusion des .class nécessaires dans mon jar) et tenter une espèce de 'concaténation' de manifest...

D'autres idées concernant la création d'un exe complètement autonome ?

Merci d'avance...

-David-

Eureka ! Je m'en suis sorti... ouf :P

En remaniant le manifest pour contenir des 'clefs de sécurité' d'activation.jar (qui se trouvaient dans le manifest de ce dernier) et en incluant les classes de chaque librairie et non les jar correspondant, j'ai pu obtenir un jar complètement autonome !

La dernière subtilité résidait dans l'utilisation des ressources (icônes, images, fichiers xml, etc...) en passant justement par l'url de ressource, c'est à dire en utilisant les getClass().getClassLoader().getResource( "nom_de_fichier" ).

Le tour étant joué côté jar, il ne restait plus qu'à créer l'exe avec JSmooth avec les bons paramètres. J'ai maintenant une application client java en .exe complètement indépendante et qui encapsule toutes les librairies et ressources dont elle a besoin...

Génial !

Encore merci à tous pour vos bons conseils ;)

A bientôt,

-David-

Citation:

---

Envoyé par adiGuba

Une solution serait donc de ne pas intégré les librairies externes dans ton jar, mais de les placer par exemple dans un répertoire lib à coté de ton Jar.

---

on n'aurait pas pu archiver de nouveau le .jar et le dossier lib,afin d'obtenir un jar regroupant le tout ?
Après tout,corriger moi si je me trompe,mais la commande jar permet de compresser le contenu d'un répértoire quel qu'il soit, non?

Sinon je viens d'essayer JSmooth, ce n'est pas mal du tout mais je ne sais pas du tout s'il est robuste, quelqu'un l'a essayé sur des projets conséquents?

Merci d'avance :wink:

Citation:

---

Envoyé par afrikha

on n'aurait pas pu archiver de nouveau le .jar et le dossier lib,afin d'obtenir un jar regroupant le tout ?

---

Dans ce cas elles ne peuvent pas être chargé directement par l'attribut Class-Path du manifest. Il faut donc extraire les Jar pour ajouter les *.class dans le jar comme l'a fait cpr0...


Mais personellement cette solution ne me plait pas : Cela ne facilite pas les mises à jours (obligation de regénérer TOUT le jar), alors qu'en séparant les archives tu peux mettre à jours les différentes archives indépendamment (et facilement si tu déploie avec JWS)...

a++

Bonsoir afrikha,

Au sujet du jar, c'est ce que j'avais fait au début, c'est à dire intégrer les librairies telles quel dans le jar final, comme dans un zip. Le problème était ensuite pour utiliser les classes des jar 'zippés', il aurait fallu passer par un ClassLoader car il est impossible de définir un classpath interne. C'est pourquoi j'ai opté pour l'autre solution, c'est à dire intégrer à mon jar les classes des librairies.

En ce qui concerne JSmooth, l'application à laquelle j'aboutis est relativement conséquente. Elle utilise au moins une douzaine de jar qui vont de parsers xml à des librairies pour envoyer des mails et bien d'autres. Au final, l'exe en lui même fait autour de 5 Mo, c'est une appli client, interface swing, qui communique avec une appli serveur via des web services autour d'Axis sous Tomcat.

A+

-David-

d'accord, merci :wink:
autre petite question qui est peut-etre un peut H.S mais qui ne merite pas non plus un topic à elle seule:
j'ai projet dont les repertoires sont:

Code:

---

1 2 3 4 5 6 7 8

projet | -sources | -classes | -images

---

comment faut-il definir le chemin des images dans le code pour avoir

Code:

---

1 2 3 4 5 6 7 8

projet | -sources | -classes | -images

---

pour l'instant j'ai mis "images/image1.png" .

c'est peut etre une erreur de classpath !!, mais le classpath n'est utilisé que par javac et non par java ,ou bien les deux ?

autre petite question, si je mets ce projet dans un jar,est-ce que l'arborescence sera respectée?

Je suis d'accord avec toi adiGuba et c'est en général comme cela que je procède. Cette fois-ci les besoins pour mon client étaient un peu différents. L'application devant être installée sur des portables, pour des utilisateurs lamda, ne sachant pas ce qu'est un jre ou un jdk, l'exécutable était une solution très appropriée.

De plus, la partie cliente n'est pas la partie la plus sensible, c'est surtout l'appli serveur et ses web services qui occupent le plus gros du projet.

Pour finir, grâce à ant et Eclipse la mise à jour de l'exécutable est vraiment un jeu d'enfant ;)

Bonne soirée,

-David-

@ afrikha

Le classpath est utilisé à la fois par le compilateur et par la JVM pour retrouver les classes ou les resources de ton application.
Dans un Jar le classpath correspond à la racine du Jar (donc le fichier /com/package/Objet.class correspond à la classe com.package.Objet).

Pour les resources c'est la même chose...


@ cpr0 : je suis d'accord que cela dépend bien sûr de l'application et du client ;)

a++

merci beaucoup :wink:

Attention afrikha, ne mets pas des images sous ton répertoire de classes, ce n'est pas très 'esthétique' on va dire ;)
Je te propose l'arborescence que j'utilise :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

projet | +--src (sources java *.java) | +--build (les java compilés *.class) | +--etc | +--res (racine des ressources) | +--img (les images avec éventuellement d'autres sous-répertoires) | +--xml (pour des fichiers xml par exemple) ...

---

Lorsque tu crées ton jar, ton archive doit comporter l'arborscence suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

/ | +--com (package racine, ici de la comiplation des .java) | | | +-- ss_package1 (ss package, etc...) | +--etc | +--res (les ressources et leur sous-répertoires comme au-dessus) ...

---

A toi de bien définir ton build.xml pour générer le jar à l'aide de ant.

Pour accéder aux ressources tu passeras par un getResource, exemple (non testé) pour une image :

Code:

---

1 2	Image image = (new ImageIcon( this.getClass().getClassLoader().getResource( "etc/res/img/mon_image.jpg" ) )).getImage();

---

La jvm crée alors un lien entre l'emplacement de ton jar et l'image dans le jar, quelque chose du style :

jar:/C://rep/ss-rep/monappli.jar!etc/res/img/mon_image.jpg (il s'agit d'une url)

C'est quand même bien fait :) Si tu veux exécuter l'application avec Eclipse, il ne faut pas oublier d'ajouter un accès au ressources (bootstrap add folder) dans les propriétés/build path de Run...

Je te laisse fouiller un peu.

A+

-David-

merci, j'aurai jamais trouvé tout seul :wink:

je croyais que build.xml de ant devait etre placer à la racine du projet?

Bonjour afrikha,

Qu'est-ce qui te faire dire que j'ai pensé le contraire ??? Mon build.xml est toujours à la racine de mon projet ! Même si, à priori, ça ne pose pas de problème de le mettre ailleurs. Mais autant le laisser à la racine effectivement...

Bonne journée,

-David-

ben comme j'ai vu un dossier XML... mais j'ai tiré des conclusions atives, désolé.
sinon merci de ton aide :D

Ha ok ! Non, ce n'était pas le répertoire de build.xml mais un exemple de répertoire de ressources xml ! On utilise énormément le xml maintenant, donc c'était un exemple pertinent je pense ;)

Je t'en prie pour mon aide, si ça a pu te servir, alors tant mieux :)

A bientôt,

-David-