Problème de path

Bien le bonjour,

J'ai un souci pour retrouver le path d'un programme java. Lorsque je fais :

Code:

---

1 2	jTextArea1.setText(System.getProperty("java.class.path"));

---

Lorsque je lance mon application, j'obtiens comme réponse :

Code:

---

1 2	/home/alexandre/Java/JTestAppli-3/build/classes:/home/alexandre/Java/JTestAppli-3/src

---

Normalement je devrais retrouver le path soit /home/alexandre/Java/JTestAppli-3/src.

Donc ai-je une solution pour palier à ce problème ?

Le dossier src n'est pas le dossier compilé.
Pourquoi souhaites-tu retrouver le dossier du code source ?
Une fois ton application déployée, ce dossier n'y sera peut-être même pas non ?

Pourquoi ?

Afin d'ajouter automatiquement un fichier de configuration qui se crée à la volé. Donc en test ça doit fonctionné et en déployé aussi !

Citation:

---

Envoyé par Microbulle

Donc en test ça doit fonctionné et en déployé aussi !

---

Justement, le dossier source n'est donc pas un bon emplacement vu qu'il n'est que rarement déployé.
Utilise plutôt user.dir ou user.home

Bon et bien je vais surement faire autrement.

Je vais m'attaquer à une classe qui aura un getter qui fera la chose suivante :

Citation:

---

Algorithmie
Point d'entrée (rien)
Détection du système d'exploitation
Si c'est Windows 95 -> placer sous C:/(je connais pas la suite)
Si c'est Windows 98 -> placer sous C:/(je connais pas la suite)
Si c'est Windows 2000 -> placer sous C:/(je connais pas la suite)
Si c'est Windows XP -> placer sous C:/(je connais pas la suite)
Si c'est Windows VISTA -> placer sous C:/(je connais pas la suite)
Si c'est Windows SEVEN -> placer sous C:/(je connais pas la suite)
Si c'est Linux -> placer sous (je connais pas la suite)
Si c'est Solaris -> placer sous (je connais pas la suite)
Si c'est Free BSD -> placer sous (je connais pas la suite)
Si c'est Mac OSX -> placer sous (je connais pas la suite)
Si c'est d'autres OS -> (je connais pas la suite)
Point de sortie (String Chemin en fonction de l'OS)

---

Sous réserve que chaque OS soit disponible.

Personnellement je connais XP et SEVEN, Ubuntu mais les autres je ne sait pas. Existe-t-il une doc ou est indiqué en fonction de l' OS ou on doit placé les fichiers de variables ? Existe-t-il une doc ou on sait quel OS est compatible avec la console JAVA ?

Je pense qu'ainsi on aura résolu le problème principal tout en faisant une classe propre et utilisable.

Perso j'utilise user.home avec un sous-dossier, l'avantage c'est que c'est multiplatform.

Et beh... si j'avais sus !
Donc null besoin de savoir sur quel OS!
Merci beaucoup pour cette info :)

Citation:

---

Afin d'ajouter automatiquement un fichier de configuration qui se crée à la volé. Donc en test ça doit fonctionné et en déployé aussi !

---

Caalador a raison.
Les sources c'est pour le développeur et le livrable (classes compilés + autres fichiers) c'est pour l'utilisateur.

Pour utiliser ton application, les utilisateurs ne pourront rien faire avec les sources de ton appli, ils ont besoin du bytecode.
A moins de les obliger à compiler eux même l'application à partir des sources.

On a peut-être pas bien compris ton problème. N'hésite pas à expliquer davantage tes motivations sur le fichier de configuration :
Qui a besoin de ce fichier de configuration ?
L'utilisateur final de l'application ?
Et il sert à quoi ?

Parce que la tu pars sur un chantier super compliqué et vraiment enclin aux bugs ...

Pour le moment je suis en train de travaillé sur une classe d'enregistrement de données.

A partir de ce code, je me charge d'essayer de créer des fiches. Actuellement ces fiches servent à des joueurs et pour stocker leurs paramètres logiciel tel que fond d'écran, connexion à un serveur distant, etc... Donc ce fichier de base se trouvera normalement toujours au même endroit, avec le soft (d'ou ma recherche de raçine), car s'il est héberger sur clef usb alors... Du coup je mettais toujours mes fichiers avec le jar et ça ne posait jamais de problème.

Le fait qu'un jar puisse être lancé de n'importe ou, pose ce problème. Voila pourquoi si il y avait une convention, je l'aurais prise en compte...

Citation:

---

Le fait qu'un jar puisse être lancé de n'importe ou, pose ce problème. Voila pourquoi si il y avait une convention, je l'aurais prise en compte...

---

A partir du moment où coté client, le jar et les fichier de configuration du joueur sont au même niveau dans le répertoire d'installation, tu ne devrais pas avoir de problème.
Lorsque ton application (ton jar) aura besoin de lire le fichier de configuration du joueur, il te suffira d'utiliser la propriété système 'user.dir' qui indique à partir d'où le jar a été lancé pour en déduire ou se trouve ton fichier de configuration.
Exemple (j'ai utilisé plusieurs variables pour découper la logique):

Code:

---

1 2 3 4

String currentDir = System.getProperty("user.dir"); File parentDir = new File (currentDir); File ficheUser = new File(parentDir, "ficheUser.data");

---

Après si l'utilisateur déplace manuellement le jar de sorte qu'il ne soit plus au même niveau que les fichiers de configuration, c'est normal que ca ne fonctionne plus.
Ex : Si tu déplaces le fichier de sauvegarde d'un jeu à un endroit non prévu par le jeu, la sauvegarde n'est pas visible.

Ben pour tes fiches user c'est pareil. Il faut voir le jar ici comme un simple fichier exécutable, pas plus, pas moins.

Ça y est, ça fonctionne :ccool:

Je rouvre le sujet !

Je me suis rendu compte de la chose suivante,
Lorsque on test l'application, on a pas le même résultat que lorsque on la compile !

Pourquoi ?

N'existe-t-il pas un endroit commun à tous les systèmes ou sont les fichiers de configurations ?
Existe-t-il une classe permettant à coup sûr de les placé au bon endroit ?

Après-coup, je ne verrais aucun inconvénient à ne placer mes fichiers utilisateur qu' a un seul endroit, juste que ça serais plus simple à cotés de l'exécutif (ici un .jar)...

heu je doit avouer que après la lecture de tout les post je n'est toujours pas compris le problème tu veut simplement retrouver ton fichier quand ton jeux a déjà était configuré par un joueur)

pourquoi tu ne place pas ce fichier a coté de ton Jar ou dans un sous dossier

Citation:

---

Mon.jar
MaConf.data

ou alors

Mon.jar
-Configuration
MaConf.data

---

et dans ce cas c'est très simple

Code:

---

1 2 3 4 5 6

File conf = new File("MaConf.data");   ou   File conf = new File("configuration/MaConf.data");

---

après une subtilité m'a peut être échappé

En fait j'ai laisser tomber le jeu mais dans un cas actuelle, je fais tourné le même soft de plusieurs façon.

Sur un pc windows (dans un D:/)
Sur un linux (dans un /home)
Sur une clef USB en mode nomade (tantôt G:/soft/, tantôt Key/Soft)...

Donc le fichier de conf se crée depuis le programme et dois pas changer de place !

bonjour,

pourquoi ne pas créer un fichier ini avec l'objet properties ?
http://forums.sun.com/thread.jspa?threadID=5330912

par défaut, il se trouvera toujours dans le même dossier que le jar.

heu non auteur, "le même endroit que le jar" est quelque chose de dur à déterminer (le jar peux ne pas exister, il peux y avoir plusieurs jar, on peux avoirs des classloader particulier comme dans le cas d'une servlet). Si tu veux déployer ton application pour qu'elle marche de manière nomade avec le .ini que tu stockerais à coté du jar, il vaut mieux,

coté code:
créer / sauver le ficheir dans le répertoire courant

coté déploiement:
créer un .bat/.sh qui fixe correctement le répertoire courant (cd)

Normalement il n'y qu'une classe main non ? :koi:
Si je fais un

Code:

---

File file = new File("test.ini")

---

(comme dans l'exemple du lien), le fichier ini ne sera pas créé dans le même dossier ?

il sera créé dans "le répertoire courant".

Ainsi si je fait

Code:

---

1 2	cd /tmp java -jar /mnt/cleUsb/monjar.jar

---

le fichier sera créé dans /tmp

si je fait

Code:

---

1 2	cd /mnt/cleUsb/ java -jar /mnt/cleUsb/monjar.jar

---

le fichier sera créé dans /mnt/cleUsb/monjar.jar


d'ou l'intérêt de faire un .sh qui aille dans le bon répertoire, ce genre là

Code:

---

1 2 3 4 5 6

#!/bin/sh   #move to script folder cd `dirname $0` #run jar present in same folder as script java -jar monjar.jar

---

Si ton script n'est pas toujours lancé depuis le même répertoire, je pense que la solution dont il était question au début du thread (home.dir) est une bonne solution.

C'est crossplateforme, tu gardes un répertoire constant. La seule chose que tu perd, c'est par exemple si lancé depuis une clé USB, le fichier ne sera pas sur la clé, et donc si tu passe la clé sur un autre poste, tu perd ta conf. Mais, dans l'esprit, je pense que ça colle à la notion de configuration utilisateur.

Oué !
Je pense aussi que c'est la solution.

Ce que j'ai fait, c'est un bout de code pour voir ce que voyais chaque système. Et il s'avère que windows placerais à cotés du jar alors que linux resterais au /home/user de la machine.

Donc j'ai adopter la première méthode laissant ainsi le système faire son travail. Il faudra re initialisé pour chaque cas. Et là, plus de souci !