Discussion :

[tchize_]

pour information, le répertoire courant (puisque c'est ce que tu affiche apparement) est imprévisible pour l'application, il vaut donc mieux éviter de l'utiliser.

[arkhamon1]

j'ai fait une tentative de copier mon appli sur une autre machine MAC.
J'ai créé un dossier /brahma dans lequel j'ai copié tous les fichiers .class.
Ensuite j'ouvre un terminal, et je fais les commandes suivantes :

Code :

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

1
2
cd /
java -classpath /brahma brahma.brahma

et j'obtiens cette fichue exception : NoClassDefFoundError

JE comprends plus rien...

[arkhamon1]

pour information, le répertoire courant (puisque c'est ce que tu affiche apparement) est imprévisible pour l'application, il vaut donc mieux éviter de l'utiliser.

OK. Du coup ce qui m'intéresse, c'est d'avoir le répertoire ou si situe l'exécutable (ou le .class) de l'application. En fait j 'ai toute une arborescence de fichiers à partir du répertoire dans lequel se trouve l'appli, et je voudrais que ca puisse être installé n'importe où. D'où la nécessité d'avoir quelque chose de stable (autre que forcer un répertoire d'installation). Ca règlerait je suppose cette bizarrerie des dossiers.

Je bloque encore su rla diffusion de l'appli (voir autre post). D'ailleurs, existe-t-il un tuto TRES simple (j'ai visiblement toujours pas compris comment fonctionne Java) qui explique ce genre de choses ? En sachant prendre des cas simples...

[tchize_]

Alors, plusieurs chose, quand vous tappez:

Code :

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

java -classpath /brahma brahma.brahma

Ca suppose qu'il existe un fichier /brahama/bramha/brahma.class

Le premier étant le répertoire pointé par votre commande -classpath, le deuxième étant le nomb du package que vous avez mentionné, le troisième étant le nom de la classe.

Trouver le répertoire où se trouve l'applicaiton est très difficile, car cette notion n'existe pas en java. Ainsi, si je tappe

java -classpath main/:lib/librairie1.jar:lib/librairie2.jar:extensions/:datas/

quelle valeur espérez vous en ressortir??

En java, pour tout ce qui viens avec l'application, on utilise des resources, qui apparaissent sous forme d'url et non pas des File, qui nécessitent un emplacement précis sur le filesystem. A noter que ce n'est pas propre à java, le problème à résoudre est le même pour tous les language. Mais java, via les ressource, fournis une solution facile d'emploi.
On les utilise comme ça:

Code :

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

URL imageURL = getClass().getResource("/images/backgrond.png");

Ensuite, ce que vous devez faire pour la distribution:

empaqueter toutes vos classes et vos images & autres dans un .jar (voir les FAQ java pour savoir comment faire)
mettre toutes les librairies éventuelles dont vous auriez besoin dans un sous dossier à coté du jar (exemple lib/)
dans votre jar, vous aurez un fichier META-INF/MANIFEST.MF qui référencera votre main (à exécuter) et le Classpath (librairies dont l'emplacement est relatif à ce jar).
Vous aurez donc ce genre de structure portable:

Code :

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

1
2
3
4
5
application.jar
lib/
   librairie1.jar
   librairie2.jar
   librairie3.jar

que vous pourrez, par exemple zipper.


Bref, la bonne pratique c'est d'éviter d'utiliser File pour tout ce qui est supposé embarqué avec l'application. Par contre on utilise File pour tout ce qui est spécifique à l'utiliser (la config qu'on stocke dans user.home, les fichiers ouvert via une boite de dialogue, etc)

[arkhamon1]

Merci pour les infos.
Du coup, entre temps, j'ai réfléchi et en fait j'ai contourné la difficulté en transmettant le répertoire où se situent mes données en paramètres et en récupérant args[0] et ca pour le coup ca marche aussi bien sous eclipse que sous terminal. C'est pas vraiment la solution, mais ca a le mérite de marcher.
J'aurais quand même pu y penser plus tôt, ça aurait évité pas mal d'encre (ou plutôt de touches clavier... ).
Pour constituer la "chose" packagée, je vais encore attendre un peu avant de m'y attaquer, j'ai tellement d'autres choses à voir (générer un PDF, faire des fenêtres ui ressemblent à quelque chose, sauver mes fichiers, manipuler les fichiers XML, régler ces foutus problèmes d'encodage, et surtout me retaper les 23000 lignes de code de mon appli... ).
En tout cas merci pour l'aide. Même si j'ai pas tout compris, ça m'a permis d'avancer...

[tchize_]

Merci pour les infos.
Du coup, entre temps, j'ai réfléchi et en fait j'ai contourné la difficulté en transmettant le répertoire où se situent mes données en paramètres et en récupérant args[0]

En général, pour éviter de convonfre avec les argument, il arrive qu'on fasse ce genre de chose:

Code :

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

java -DAPPLICATION_HOME=xxxx <reste des paramètres>

et

Code :

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

System.getProperty("APPLICATION_HOME");

je l'ai pas évoqué car, pour la distribution, ca nécessite de passer par un installeur qui créera les .bat / .sh en y injectant le répertoire d'installation choisi par l'utilisateur.


Pour les ressources, je recommande d'y jeter un oeil assez vite. Car une fois la machine en marche, c'est du boulot de remplacer tous les File par des getResouce

[arkhamon1]

En java, pour tout ce qui viens avec l'application, on utilise des resources, qui apparaissent sous forme d'url et non pas des File, qui nécessitent un emplacement précis sur le filesystem. A noter que ce n'est pas propre à java, le problème à résoudre est le même pour tous les language. Mais java, via les ressource, fournis une solution facile d'emploi.
On les utilise comme ça:

Code :

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

URL imageURL = getClass().getResource("/images/backgrond.png");

Quand vous marquez

Code :

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

URL imageURL = getClass().getResource("/images/backgrond.png");

le "/images/background.png" est censé se situer où exactement ? dans un sous dossier de ..../bin, ou dans un de l'appli ? C'est là ou j'ai un peu de mal... En fait ce que je comprends pas c'est pourquoi le getResource trouverait plus facilement le fichier...

Ensuite, ce que vous devez faire pour la distribution:

empaqueter toutes vos classes et vos images & autres dans un .jar (voir les FAQ java pour savoir comment faire)
mettre toutes les librairies éventuelles dont vous auriez besoin dans un sous dossier à coté du jar (exemple lib/)
dans votre jar, vous aurez un fichier META-INF/MANIFEST.MF qui référencera votre main (à exécuter) et le Classpath (librairies dont l'emplacement est relatif à ce jar).
Vous aurez donc ce genre de structure portable:

Code :

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

1
2
3
4
5
application.jar
lib/
   librairie1.jar
   librairie2.jar
   librairie3.jar

que vous pourrez, par exemple zipper.


Bref, la bonne pratique c'est d'éviter d'utiliser File pour tout ce qui est supposé embarqué avec l'application. Par contre on utilise File pour tout ce qui est spécifique à l'utiliser (la config qu'on stocke dans user.home, les fichiers ouvert via une boite de dialogue, etc)

Du coup le fameux .jar va contenir toute l'appli c'est ça ? Du coup si je veux juste livrer un fichier .class que je viens de modifier, je dois relivrer le jar complet ?

[tchize_]

Quand vous marquez

Code :

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

URL imageURL = getClass().getResource("/images/backgrond.png");

le "/images/background.png" est censé se situer où exactement ? dans un sous dossier de ..../bin, ou dans un de l'appli ? C'est là ou j'ai un peu de mal... En fait ce que je comprends pas c'est pourquoi le getResource trouverait plus facilement le fichier...

Dans le classpath. Donc, par exemple, dans le même jar. Sous eclipse, vous pouvez par exemple créer une répertoire ressource. Puis bouton droit -> add to build path. ainsi si vous avez un fichier ressource/images/background.png, il aura le nom "/images/background.png" dans le classpath.

Du coup le fameux .jar va contenir toute l'appli c'est ça ? Du coup si je veux juste livrer un fichier .class que je viens de modifier, je dois relivrer le jar complet ?

Oui, en même temps, c'est plus propre de livre le jar complet que de livrer des .class individuel et prier que la personne de l'autre coté les places au bon endroit . Une application c'est en général beaucoup de classes, traiter leur mise à jour individuelle, c'est suicidaire

[verbose]

Si je ne trompe pas, tu définis un chemin relatif pour trouver ton fichier xml.

Si c'est bien le cas, cela explique la différence entre une exécution par Eclipse, et une exécution en ligne de commande.

La particularité d'Eclipse, c'est que le répertoire racine est celui du projet. Par exemple /home/user/workspace/monprojet. Ce répertoire contient les dossiers bin et src dans lesquels se trouvent les sources et les fichiers compilés.

Alors qu'en ligne de commande, le répertoire racine est celui qui contient les fichiers .class. Par exemple /home/user/workspace/monprojet/bin

Donc, si tu définis un chemin relatif, celui-ci ne pointera pas sur le même chemin absolu sous Eclipse et en ligne de commande.

C'est un peu con il faut bien l'avouer, c'est pour ça qu'il est préférable de placer ses fichiers statiques dans le classpath et les récupérer comme l'indique tchize.

[EDIT] Je n'avais pas vu qu'il y avait une deuxième page sur ce topic, donc mon message est un peu hors de propos [/EDIT]

[arkhamon1]

Rassures toi, ta réponse me donne l'explication de ce que je comprenais sans maitriser : la différence du chemin de base.
Donc sans savoir comment régler ce problème, je l'ai contourné en utilisant un paramètre transmis sur la ligne de commande.
Merci quand même.

[tchize_]

Alors qu'en ligne de commande, le répertoire racine est celui qui contient les fichiers .class. Par exemple /home/user/workspace/monprojet/bin

pas nécesssairement, comme déjà dit, c'est pas prévisible pour l'application

[verbose]

pas nécesssairement, comme déjà dit, c'est pas prévisible pour l'application

Effectivement, le chemin exact n'est pas prévisible et dépend du répertoire d'installation de l'application. Mais d'une manière générale, le répertoire pointé par un chemin relatif dépend du répertoire qui contient les fichiers .class, ou le .jar. Après, ces fichiers .class et ce jar peuvent se situer n'importe où dans le système de fichier.

[tchize_]

d'une manière générale, le répertoire pointé par un chemin relatif dépend du répertoire qui contient les fichiers .class, ou le .jar.

Non justement. Ca dépend uniquement du répertoire courant au moment où je lance l'application (bref le dernier "cd" que j'ai effectué)

Si de tappe:

Code :

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

1
2
cd c:\
java -cp "c:\Mes documents\monApplication\bin"  mon.Application

Les chemins relatifs se feront par rapport à c:\ et non pas par rapport à c:\Mes documents\monApplication\bin.

[verbose]

Ah oui effectivement

Bien vu