2010-04-25 4 views
6

Je stocke généralement les applications Java et les fichiers JAR que je télécharge depuis le Web dans le dossier ~/Java de mon ordinateur (un ordinateur OS X). Je fais cela depuis l'époque où j'étais un utilisateur de Windows. Cependant, je pense que dans les systèmes basés sur UNIX, les applications locales des utilisateurs sont classiquement stockées dans un autre répertoire. J'ai le sentiment que ce répertoire devrait être soit /usr/local/, /usr/local/USERNAME, /opt/local, ou /opt/local/USERNAME mais je ne suis pas sûr. Des idées quel répertoire puis-je utiliser à cette fin?L'emplacement conventionnel pour stocker mes bibliothèques et applications Java dans les systèmes UNIX

S'il vous plaît noter que, je parle de fichiers d'archive que je télécharger à partir du Web, déballer et utiliser localement et non des programmes qui ont des scripts d'installation ou MacPorts, etc.

+2

Stockez-les dans /home/USERNAME/.maybeEvenAHiddenFolder. "/ usr /" btw n'a rien à voir avec "user" mais est en fait un raccourci pour les ressources système unix. – Tedil

+2

1. OS X est un unix 2. à moins que vous ne vouliez les installer pour tous les utilisateurs du système, il n'y a rien de mal à les placer dans votre répertoire personnel. – xenoterracide

+0

@xenoterracide: Je sais! Et j'ai utilisé ~/Java pendant des années sans problème! Ma question concernait les conventions. – Behrang

Répondre

2

Il n'y a aucune manière bénie de le faire. Vous pouvez cependant avoir plusieurs versions d'un pot, et ensuite il va juste en descendant de là.

Je télécharge généralement les fichiers jars dont j'ai besoin en tant que distribution et je les décompresse dans son propre dossier, puis j'ajoute les fichiers jars aux projets dont j'ai besoin dans mon IDE. Pour les bibliothèques, une approche courante consiste à utiliser Maven et sa gestion des dépendances.

Alors, ma suggestion est de garder votre façon actuelle de le faire, si vous aimez, mais ont chaque projet dans son propre dossier, comme

~/Java/jakarta-commons-net-1.1.8/commons-net.jar 
+0

@ Thorbjørn: Je connais les conflits JAR, etc. et pour le moment je les organise exactement comme votre exemple. Cependant, je ne faisais que poser des questions sur les conventions. Il semble qu'il n'y ait pas de conventions ici ... :) – Behrang

+0

Nous utilisons toujours CVS et nous avons pris l'habitude de mettre des bibliothèques utilisées dans leur propre projet Eclipse avec la source et javadoc définies, et celles-ci sont également vérifiées dans CVS. Cela nous permet d'utiliser Import -> ProjectSet pour obtenir un espace de travail entièrement rempli sans maven et entièrement interne. –

2

Vous voudrez peut-être lire le Filesystem Hierarchy Standard/opt ou/usr/local sont probablement appropriés, mais vous devriez d'abord lire les définitions FHS.

+0

ou voir la version d'Apple http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man7/hier.7.html#//apple_ref/doc/man/7/hier Note/opt/local est utilisé par macports afin que vous puissiez être mieux sur/usr/local pour le code partagé – Mark

3

Apple ont un note don/Library/Java/Extensions en tant que répertoire pour les fichiers jar partagés et ~/Library/Java/Extensions pour les fichiers jar uniquement pour vous. Ces chemins sont sur le chemin de classe.

Les fichiers jar peuvent être n'importe où, tant que ce répertoire se trouve sur le chemin de classe. (J'utilise une version de style de Thorbjørn Ravn Andersen J'utilise ~/Bibliothèque/Jar/jakarta-commons-net-1.1.8/commons-net.jar)

Voir la réponse de Tom Anderson pour une meilleure façon de le faire Utilisation de lierre, etc.

13

La réponse partielle est que vous ne devriez pas télécharger de bocaux à la main, vous devriez utiliser Gradle, Ivy, Maven, ou quelque chose de similaire pour gérer vos pots pour vous. Ces outils prennent une spécification simple de vos dépendances en entrée, et vont chercher, télécharger, stocker et rendre disponibles tous les fichiers jar nécessaires. Cela prend un peu de temps pour s'y habituer, mais ils sont plutôt merveilleux une fois que vous êtes dans le coup.

Une réponse directe, cependant, est que sur unix orthodoxe, ces fichiers appartiennent à /usr/local/share. usr parce qu'ils sont en lecture seule des données qui ne fait pas partie du système d'exploitation de base, local parce qu'ils ne sont pas fournis par le système d'exploitation (qui est propriétaire du reste de /usr), et share parce que les fichiers jar sont indépendants de l'architecture.

Notez que sur FreeBSD, le système de gestion des paquets 'ports' place les fichiers dans /usr/local, mais je crois qu'il partage avec l'administrateur local. Il n'y a pas d'autre endroit où vont les fichiers purement locaux.

Si le système a une convention pour l'emplacement des fichiers jar gérés par le package, copiez-le sous /usr/local. Par exemple, sur Ubuntu, il y a /usr/share/java, donc vous devriez utiliser /usr/local/share/java.

En outre, si le système a une convention pour gérer les versions, copiez-le. Encore une fois, sur Ubuntu, les fichiers jars sont tous stockés dans un répertoire, avec les numéros de version dans le nom, mais avec un lien symbolique sans version pointant vers la version par défaut/dernière version. Donc, j'ai un fichier à /usr/share/java/xstream-1.3.1.jar, et un lien symbolique à /usr/share/java/xstream.jar pointant vers lui. J'utiliserais la même approche dans /usr/local/share/java.

Maintenant, c'est pour unix orthodoxe. Vous êtes sur OS X, qui n'est pas unix orthodoxe. Néanmoins, les principes s'appliquent: trouvez comment le système stocke les fichiers jar qu'il fournit et transposez-les dans un espace de système de fichiers géré par l'utilisateur.

1

Sur les systèmes FreeBSD, l'emplacement est ${LOCALBASE}/share/java - et ses sous-répertoires. Ce n'est pas que tous les logiciels-ports le respectent, mais ils devraient le faire.

LOCALBASE est généralement /usr/local - sauf si elle a été écrasée par l'administrateur système.

Questions connexes