Variable d’environnement CLASSPATH CLOSSPATH de Clojure. Pourquoi?

Ici, je vérifie la variable d’environnement CLASSPATH
daniel @ daniel-laptop: ~ / ps / clojure / projets / ring-tutorial $ echo $ CLASSPATH
/ home / daniel / ps / clojure / projets / ring-tutorial / src

Ici, je vérifie ce que java pense.
daniel @ daniel-laptop: ~ / ps / clojure / projects / ring-tutorial $ lein repl
Clojure 1.1.0 user => (System / getProperty “java.class.path”)
“src /: classes /: / home / daniel / .m2 / repository / leiningen / leiningen / 1.1.0 / leiningen-1.1.0-standalone.jar: lib / clojure-1.1.0.jar: lib / servlet-api -2.5-6.1.14.jar: lib / commons-io-1.4.jar: lib / clj-stacktrace-0.1.0.jar: lib / clojure-consortingb-1.1.0.jar: lib / ring-devel-0.2 .0.jar: lib / jetty-util-6.1.14.jar: lib / clj-html-0.1.0.jar: lib / ring-jetty-adapter-0.2.0.jar: lib / jetty-6.1.14 .jar: lib / ring-core-0.2.0.jar: lib / commons-fileupload-1.2.1.jar: lib / ring-servlet-0.2.0.jar: lib / commons-codec-1.4.jar: ”

Comme vous pouvez le voir, les deux réponses sont complètement différentes. Je suis à peu près sûr que je devrais être incompréhensible là où je devrais éditer la variable CLASSPATH pour que java le comprenne, sauf que tout ce que j’ai trouvé indique que cela devrait fonctionner. Alors, quel est le problème? Est-ce que leiningen crée son propre cas de renégat bizarre? Est-ce que je modifie une variable complètement hors de propos? Toute aide très appréciée.

$CLASSPATH est en effet complètement sans importance ici. C’est ce que java -the-JVM-launcher-program utiliserait si aucune information de classpath ne lui était fournie sur la ligne de commande; Leiningen fournit à la JVM un classpath approprié au projet sur lequel vous travaillez.

Dans ce cas particulier, "/home/.../ring-tutorial/src" ne serait pas un "/home/.../ring-tutorial/src" très utile pour le didacticiel Ring, car il ne comprend que la source du didacticiel Ring et n’inclut pas le jar Clojure (nécessaire pour exécuter le code Clojure), les jarres Ring (Ring est un projet multi-module) ou l’un des autres jars dont Ring dépend. Le classpath produit par Leiningen peut sembler long, mais tous ses composants doivent vraiment être présents.

Incidemment, si vous commencez tout juste avec Clojure, je vous recommande de vous en tenir autant que possible aux fonctions de gestion de classpath de votre toolchain (ce qui pourrait signifier Emacs + lein swank ou un IDE + le plugin Clojure). Sinon, il y a beaucoup de questions sur les problèmes de classpath de Clojure ici sur SO, ainsi qu’une multitude d’autres ressources sur le sujet que vous pouvez rechercher sur Google … mais maintenant cet outil est assez robuste et vous n’avez normalement pas besoin de toucher classpath by main, c’est juste la douleur à éviter au début.

Le problème avec l’utilisation de la variable CLASSPATH pour gérer vos dépendances est que tous les langages Java et les autres langages JVM doivent le manipuler à leurs fins. Il ne faut pas longtemps avant que vous vous soyez peint dans le coin.

Cela fonctionne quand vous lancez un serveur qui ne lance qu’un serveur. Il se décompose complètement sur un PC de développeur Java, qui a 10 programmes et projets nécessitant tous des dépendances différentes et passe ensuite plus de temps à déboguer les scripts bash pour manipuler la variable CLASSPATH qui écrit le code source.

Par conséquent, cette façon de gérer le classpath est devenue obsolète, préférant les autres techniques de chargement de classes, ou lors de l’utilisation de CLASSPATH, ne l’utilisant que très localement.

Le classpath de Clojure est le classpath de Java.

$CLASSPATH est ignoré lorsque l’exécutable java est appelé avec l’argument -cp , ce que fait Leiningen (et la plupart des scripts de compilation Clojure).

Si vous utilisez un outil de construction tel que Leiningen, vous devez l’utiliser pour gérer le classpath.