j'ai une appli java qui utilise une bonne dizaine de jars, cette appli
est lancée par une commande au terminal, commande incluant tous les jars
nécessaires.
Mais quelquefois, cela pose problème, peut-être est-ce la longueur de la
ligne de commande (je suis sous MacOS X) alors je me demande si je ne
fais pas fausse route.
Pour l'instant je met dans le classpath tous les jars dont j'ai besoin
avec leur path en absolu, ça donne quelque chose du genre :
ce qui ** me semble ** poser problème qqfois, mais pas toujours...
donc, la question est de savoir s'il n'y a pas moyen (plus élégant) de
racourcir cette liste d'arguments, par exemple en utilisant une wildcard
du genre :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TestMan
Tu peux mettre dans ton jar racine (celui qui contien ta classe main) des Class-Path (voir doc des jar pour plus d'info) en chemin relatif par rapport au fichier courrant afin d'eviter les multiples classpath.
Tant que tu y es, met un Main-Class.
Ensuite ta commande sera :
java -jar monfichierracine.jar
Top non :)
A+ TM
Yvon Thoraval wrote:
j'ai une appli java qui utilise une bonne dizaine de jars, cette appli est lancée par une commande au terminal, commande incluant tous les jars nécessaires.
Mais quelquefois, cela pose problème, peut-être est-ce la longueur de la ligne de commande (je suis sous MacOS X) alors je me demande si je ne fais pas fausse route.
Pour l'instant je met dans le classpath tous les jars dont j'ai besoin avec leur path en absolu, ça donne quelque chose du genre :
ce qui ** me semble ** poser problème qqfois, mais pas toujours...
donc, la question est de savoir s'il n'y a pas moyen (plus élégant) de racourcir cette liste d'arguments, par exemple en utilisant une wildcard du genre :
où y a t'il une doc sur la manière de gérer le classpath ???
Tu peux mettre dans ton jar racine (celui qui contien ta classe main)
des Class-Path (voir doc des jar pour plus d'info) en chemin relatif par
rapport au fichier courrant afin d'eviter les multiples classpath.
Tant que tu y es, met un Main-Class.
Ensuite ta commande sera :
java -jar monfichierracine.jar
Top non :)
A+
TM
Yvon Thoraval wrote:
j'ai une appli java qui utilise une bonne dizaine de jars, cette appli
est lancée par une commande au terminal, commande incluant tous les jars
nécessaires.
Mais quelquefois, cela pose problème, peut-être est-ce la longueur de la
ligne de commande (je suis sous MacOS X) alors je me demande si je ne
fais pas fausse route.
Pour l'instant je met dans le classpath tous les jars dont j'ai besoin
avec leur path en absolu, ça donne quelque chose du genre :
ce qui ** me semble ** poser problème qqfois, mais pas toujours...
donc, la question est de savoir s'il n'y a pas moyen (plus élégant) de
racourcir cette liste d'arguments, par exemple en utilisant une wildcard
du genre :
Tu peux mettre dans ton jar racine (celui qui contien ta classe main) des Class-Path (voir doc des jar pour plus d'info) en chemin relatif par rapport au fichier courrant afin d'eviter les multiples classpath.
Tant que tu y es, met un Main-Class.
Ensuite ta commande sera :
java -jar monfichierracine.jar
Top non :)
A+ TM
Yvon Thoraval wrote:
j'ai une appli java qui utilise une bonne dizaine de jars, cette appli est lancée par une commande au terminal, commande incluant tous les jars nécessaires.
Mais quelquefois, cela pose problème, peut-être est-ce la longueur de la ligne de commande (je suis sous MacOS X) alors je me demande si je ne fais pas fausse route.
Pour l'instant je met dans le classpath tous les jars dont j'ai besoin avec leur path en absolu, ça donne quelque chose du genre :
ce qui ** me semble ** poser problème qqfois, mais pas toujours...
donc, la question est de savoir s'il n'y a pas moyen (plus élégant) de racourcir cette liste d'arguments, par exemple en utilisant une wildcard du genre :
où y a t'il une doc sur la manière de gérer le classpath ???
yvon.thoravalNO-SPAM
TestMan wrote:
Tu peux mettre dans ton jar racine (celui qui contien ta classe main) des Class-Path (voir doc des jar pour plus d'info) en chemin relatif par rapport au fichier courrant afin d'eviter les multiples classpath.
ah ouais ! j'avais pas vu ça : Class-Path: servlet.jar infobus.jar acme/beans.jar
dans le manif-est :)
seul pb c'est en dur. -- yt
TestMan <test@example.com> wrote:
Tu peux mettre dans ton jar racine (celui qui contien ta classe main)
des Class-Path (voir doc des jar pour plus d'info) en chemin relatif par
rapport au fichier courrant afin d'eviter les multiples classpath.
ah ouais ! j'avais pas vu ça :
Class-Path: servlet.jar infobus.jar acme/beans.jar
Tu peux mettre dans ton jar racine (celui qui contien ta classe main) des Class-Path (voir doc des jar pour plus d'info) en chemin relatif par rapport au fichier courrant afin d'eviter les multiples classpath.
ah ouais ! j'avais pas vu ça : Class-Path: servlet.jar infobus.jar acme/beans.jar
dans le manif-est :)
seul pb c'est en dur. -- yt
TestMan
ah ouais ! j'avais pas vu ça : Class-Path: servlet.jar infobus.jar acme/beans.jar dans le manif-est :) seul pb c'est en dur.
Bjour, Emm... je vois pas ou est ton PB, si c'est pour coder de la config de ton appli la liste des JAR sont en dur généralement (enfin à un moment T de l'histoire de l'appli en tout cas). Et si il y a une maintenance de l'appli, il faudra juste le faire évoluer selon les besoins.
Si tu as besoins de plugin, genre le meme principe que le "ext" alors là je pense que tu pourrais regarder autour des mechanismes de SPI de Java ;-)
A+ TM
ah ouais ! j'avais pas vu ça :
Class-Path: servlet.jar infobus.jar acme/beans.jar
dans le manif-est :)
seul pb c'est en dur.
Bjour,
Emm... je vois pas ou est ton PB, si c'est pour coder de la config de
ton appli la liste des JAR sont en dur généralement (enfin à un moment T
de l'histoire de l'appli en tout cas). Et si il y a une maintenance de
l'appli, il faudra juste le faire évoluer selon les besoins.
Si tu as besoins de plugin, genre le meme principe que le "ext" alors là
je pense que tu pourrais regarder autour des mechanismes de SPI de Java ;-)
ah ouais ! j'avais pas vu ça : Class-Path: servlet.jar infobus.jar acme/beans.jar dans le manif-est :) seul pb c'est en dur.
Bjour, Emm... je vois pas ou est ton PB, si c'est pour coder de la config de ton appli la liste des JAR sont en dur généralement (enfin à un moment T de l'histoire de l'appli en tout cas). Et si il y a une maintenance de l'appli, il faudra juste le faire évoluer selon les besoins.
Si tu as besoins de plugin, genre le meme principe que le "ext" alors là je pense que tu pourrais regarder autour des mechanismes de SPI de Java ;-)
A+ TM
yvon.thoravalNO-SPAM
TestMan wrote:
Emm... je vois pas ou est ton PB, si c'est pour coder de la config de ton appli la liste des JAR sont en dur généralement (enfin à un moment T de l'histoire de l'appli en tout cas). Et si il y a une maintenance de l'appli, il faudra juste le faire évoluer selon les besoins.
une partie des jars varie (dev) car l'appli repsoe sur des jars qui varient en nombre et en nom, work in progress.
Si tu as besoins de plugin, genre le meme principe que le "ext" alors là je pense que tu pourrais regarder autour des mechanismes de SPI de Java ;-)
oui, ça je dois le regarder pour la version définitive, merci pour l'info. -- yt
TestMan <test@example.com> wrote:
Emm... je vois pas ou est ton PB, si c'est pour coder de la config de
ton appli la liste des JAR sont en dur généralement (enfin à un moment T
de l'histoire de l'appli en tout cas). Et si il y a une maintenance de
l'appli, il faudra juste le faire évoluer selon les besoins.
une partie des jars varie (dev) car l'appli repsoe sur des jars qui
varient en nombre et en nom, work in progress.
Si tu as besoins de plugin, genre le meme principe que le "ext" alors là
je pense que tu pourrais regarder autour des mechanismes de SPI de Java ;-)
oui, ça je dois le regarder pour la version définitive, merci pour
l'info.
--
yt
Emm... je vois pas ou est ton PB, si c'est pour coder de la config de ton appli la liste des JAR sont en dur généralement (enfin à un moment T de l'histoire de l'appli en tout cas). Et si il y a une maintenance de l'appli, il faudra juste le faire évoluer selon les besoins.
une partie des jars varie (dev) car l'appli repsoe sur des jars qui varient en nombre et en nom, work in progress.
Si tu as besoins de plugin, genre le meme principe que le "ext" alors là je pense que tu pourrais regarder autour des mechanismes de SPI de Java ;-)
oui, ça je dois le regarder pour la version définitive, merci pour l'info. -- yt