Bonjour,
Un programme que je compte distribuer utilise une bibliothèque sous
forme de fichiers compilés dans un archive JAR. Cela ne pose aucun
problème avec le "run" de eclipse, mais mon programme, une fois compilé,
ne trouve plus les classes de cette bibliothèque que j'utilise.
Pourriez-vous, s'il-vous-plait, m'indiquer :
_ où je dois dire aux utilisateurs de placer le fichier JAR qui contient
la bibliothèque sur leur ordinateur ?
_ comment faire pour que mon programme les trouve ?
si ton java est dans : /usr/lib/java/jre/bin/ (le vérifier en faisant un type java sur un vrai OS) alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Le Sun, 11 Jul 2004 00:22:44 +0200, Alexandre a écrit :
Remarque : mon programme est sous forme de JAR, et la commande
si ton java est dans :
/usr/lib/java/jre/bin/
(le vérifier en faisant un type java sur un vrai OS)
alors toute bibliotheque mise dans
/usr/lib/java/jre/lib/ext
sera inclue d'office dans le classpath.
si ton java est dans : /usr/lib/java/jre/bin/ (le vérifier en faisant un type java sur un vrai OS) alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Alexandre
Unknown wrote:
si ton java est dans : /usr/lib/java/jre/bin/ (le vérifier en faisant un type java sur un vrai OS) alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Youpi ! ça marche ! Sur Win***, le répertoire peut être par exemple :
C:Program FilesJavaj2re1.4.2_04libext
Unknown wrote:
si ton java est dans :
/usr/lib/java/jre/bin/
(le vérifier en faisant un type java sur un vrai OS)
alors toute bibliotheque mise dans
/usr/lib/java/jre/lib/ext
sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Youpi ! ça marche ! Sur Win***, le répertoire peut être par exemple :
si ton java est dans : /usr/lib/java/jre/bin/ (le vérifier en faisant un type java sur un vrai OS) alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Youpi ! ça marche ! Sur Win***, le répertoire peut être par exemple :
C:Program FilesJavaj2re1.4.2_04libext
Christophe M
Alexandre wrote:
Unknown wrote:
si ton java est dans : /usr/lib/java/jre/bin/ (le vérifier en faisant un type java sur un vrai OS) alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Youpi ! ça marche ! Sur Win***, le répertoire peut être par exemple :
C:Program FilesJavaj2re1.4.2_04libext
Oui, sauf que c'est pas trop conseillé de "polluer" l'installation du jre par des librairies comme ça. Certains utilisateurs pourraient ne pas apprécier, d'autres ne pas utiliser le même runtime, ou un autre chemin pour le jre. Et puis, ça évite d'écraser des librairies existantes, et les "collisions" de nom dans les classes (imagine 2 .jar avec des noms différents, mais qui continnent les mêmes classes -enfin qui ont le même nom- Comment être sur que le système utilise la bonne classe pour ton appli ? )
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les .jar dans le répertoire de l'install de l'application, avec des chemins relatifs dans la ligne de commande de lancement.
Alexandre wrote:
Unknown wrote:
si ton java est dans :
/usr/lib/java/jre/bin/
(le vérifier en faisant un type java sur un vrai OS)
alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext
sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Youpi ! ça marche ! Sur Win***, le répertoire peut être par exemple :
C:Program FilesJavaj2re1.4.2_04libext
Oui, sauf que c'est pas trop conseillé de "polluer" l'installation du
jre par des librairies comme ça. Certains utilisateurs pourraient ne pas
apprécier, d'autres ne pas utiliser le même runtime, ou un autre chemin
pour le jre. Et puis, ça évite d'écraser des librairies existantes, et
les "collisions" de nom dans les classes (imagine 2 .jar avec des noms
différents, mais qui continnent les mêmes classes -enfin qui ont le même
nom- Comment être sur que le système utilise la bonne classe pour ton
appli ? )
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les
.jar dans le répertoire de l'install de l'application, avec des chemins
relatifs dans la ligne de commande de lancement.
si ton java est dans : /usr/lib/java/jre/bin/ (le vérifier en faisant un type java sur un vrai OS) alors toute bibliotheque mise dans /usr/lib/java/jre/lib/ext sera inclue d'office dans le classpath.
a adapté si tu es sous win***
Youpi ! ça marche ! Sur Win***, le répertoire peut être par exemple :
C:Program FilesJavaj2re1.4.2_04libext
Oui, sauf que c'est pas trop conseillé de "polluer" l'installation du jre par des librairies comme ça. Certains utilisateurs pourraient ne pas apprécier, d'autres ne pas utiliser le même runtime, ou un autre chemin pour le jre. Et puis, ça évite d'écraser des librairies existantes, et les "collisions" de nom dans les classes (imagine 2 .jar avec des noms différents, mais qui continnent les mêmes classes -enfin qui ont le même nom- Comment être sur que le système utilise la bonne classe pour ton appli ? )
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les .jar dans le répertoire de l'install de l'application, avec des chemins relatifs dans la ligne de commande de lancement.
Alexandre
Christophe M wrote:
Et puis, ça évite d'écraser des librairies existantes, et les "collisions" de nom dans les classes
Il n'y a pas de risque à priori puisque touttes les classes de la bibliothèque iText sont dans le package com.lowagie (le nom de l'auteur).
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les ..jar dans le répertoire de l'install de l'application, avec des chemins relatifs dans la ligne de commande de lancement.
C'est surement la solution la plus "proffessionelle", mais comment fait-on pour écrire les scripts de lancements avec Mac et Linux ?
Christophe M wrote:
Et puis, ça évite d'écraser des librairies existantes, et
les "collisions" de nom dans les classes
Il n'y a pas de risque à priori puisque touttes les classes de la
bibliothèque iText sont dans le package com.lowagie (le nom de l'auteur).
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les
..jar dans le répertoire de l'install de l'application, avec des chemins
relatifs dans la ligne de commande de lancement.
C'est surement la solution la plus "proffessionelle", mais comment
fait-on pour écrire les scripts de lancements avec Mac et Linux ?
Et puis, ça évite d'écraser des librairies existantes, et les "collisions" de nom dans les classes
Il n'y a pas de risque à priori puisque touttes les classes de la bibliothèque iText sont dans le package com.lowagie (le nom de l'auteur).
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les ..jar dans le répertoire de l'install de l'application, avec des chemins relatifs dans la ligne de commande de lancement.
C'est surement la solution la plus "proffessionelle", mais comment fait-on pour écrire les scripts de lancements avec Mac et Linux ?
Christophe M
Alexandre wrote:
Christophe M wrote:
Et puis, ça évite d'écraser des librairies existantes, et les "collisions" de nom dans les classes
Il n'y a pas de risque à priori puisque touttes les classes de la bibliothèque iText sont dans le package com.lowagie (le nom de l'auteur).
c'est là tout l'interet des noms de packages à rallonge ;-)
Mais imagine un autre programme qui utilise aussi iText, qui s'installe aussi dans le répertoire ext, dans un autre fichier .jar Le runtime aurait alors chargé 2 fois la même classe, dans des versions différentes. Ou plutôt, il aurait chargé la première qu'il trouve, et dont la version n'est bonne que pour 1 seul des 2 programmes. Donc il y a instabilité puisque 1 des 2 ne fonctionne plus.
C'est plus sur pour tout le monde de mettre chacun ses librairies dans son répertoire de travail/déploiement.
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les ..jar dans le répertoire de l'install de l'application, avec des chemins relatifs dans la ligne de commande de lancement.
C'est surement la solution la plus "proffessionelle", mais comment fait-on pour écrire les scripts de lancements avec Mac et Linux ?
En général, la ligne de commande est la même sur tous les os : java -cp chemindelib... -Dmonoption=valeur org.moi.maclasse
La seule grosse différence est dans les séparateurs des chemins des librairies. Après , tu fais un .bat pour windows, un .sh pour unix, un .shaipasquoi pour mac avec comme "seule" ligne la commande ci-dessus (adaptée à tes besoins évidemments)
Alexandre wrote:
Christophe M wrote:
Et puis, ça évite d'écraser des librairies existantes, et les
"collisions" de nom dans les classes
Il n'y a pas de risque à priori puisque touttes les classes de la
bibliothèque iText sont dans le package com.lowagie (le nom de l'auteur).
c'est là tout l'interet des noms de packages à rallonge ;-)
Mais imagine un autre programme qui utilise aussi iText, qui s'installe
aussi dans le répertoire ext, dans un autre fichier .jar
Le runtime aurait alors chargé 2 fois la même classe, dans des versions
différentes. Ou plutôt, il aurait chargé la première qu'il trouve, et
dont la version n'est bonne que pour 1 seul des 2 programmes. Donc il y
a instabilité puisque 1 des 2 ne fonctionne plus.
C'est plus sur pour tout le monde de mettre chacun ses librairies dans
son répertoire de travail/déploiement.
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les
..jar dans le répertoire de l'install de l'application, avec des
chemins relatifs dans la ligne de commande de lancement.
C'est surement la solution la plus "proffessionelle", mais comment
fait-on pour écrire les scripts de lancements avec Mac et Linux ?
En général, la ligne de commande est la même sur tous les os :
java -cp chemindelib... -Dmonoption=valeur org.moi.maclasse
La seule grosse différence est dans les séparateurs des chemins des
librairies.
Après , tu fais un .bat pour windows, un .sh pour unix, un .shaipasquoi
pour mac avec comme "seule" ligne la commande ci-dessus (adaptée à tes
besoins évidemments)
Et puis, ça évite d'écraser des librairies existantes, et les "collisions" de nom dans les classes
Il n'y a pas de risque à priori puisque touttes les classes de la bibliothèque iText sont dans le package com.lowagie (le nom de l'auteur).
c'est là tout l'interet des noms de packages à rallonge ;-)
Mais imagine un autre programme qui utilise aussi iText, qui s'installe aussi dans le répertoire ext, dans un autre fichier .jar Le runtime aurait alors chargé 2 fois la même classe, dans des versions différentes. Ou plutôt, il aurait chargé la première qu'il trouve, et dont la version n'est bonne que pour 1 seul des 2 programmes. Donc il y a instabilité puisque 1 des 2 ne fonctionne plus.
C'est plus sur pour tout le monde de mettre chacun ses librairies dans son répertoire de travail/déploiement.
Il est beaucoup plus propre de faire comme indiqué plus tôt : tous les ..jar dans le répertoire de l'install de l'application, avec des chemins relatifs dans la ligne de commande de lancement.
C'est surement la solution la plus "proffessionelle", mais comment fait-on pour écrire les scripts de lancements avec Mac et Linux ?
En général, la ligne de commande est la même sur tous les os : java -cp chemindelib... -Dmonoption=valeur org.moi.maclasse
La seule grosse différence est dans les séparateurs des chemins des librairies. Après , tu fais un .bat pour windows, un .sh pour unix, un .shaipasquoi pour mac avec comme "seule" ligne la commande ci-dessus (adaptée à tes besoins évidemments)
