If I add the following require:
(ns project.core
(:require
[compojure.route :as route])
(:gen-class))
(defn -main [& {:as args}]
(println "hello"))
an do
lein run
I get
Syntax error macroexpanding clojure.core/ns at (ring/util/mime_type.clj:1:1).
((require [clojure.string :as str])) - failed: Extra input spec: :clojure.core.specs.alpha/ns-form
is there a way I can get
"compojure.route not found; not defined; or whatever" e.g. something meaningful?
if I remove it it works fine. e.g. it says Hello
using Leiningen 2.9.4 on Java 14.0.1 OpenJDK 64-Bit Server VM
The project you are using is using very old dependencies. Clojure spec (introduced "recenlty") added macro/compile time checks and the mentioned file there triggers it.
compojure.route actually is found and it then requires its transitive deps. And while going down the chain ring.util.mime-type is required and the version you are using is not ready for current Clojure versions.
Your best bet here is to upgrade your deps. E.g. if you are following a book or if you are using a template this things can happen. If you have lein-ancient installed, it can attempt the update for you. Otherwise your best bet is to start in your project.clj and compare versions (e.g. check clojars).
If the problem still persists, have a look at lein deps :tree and see what is going on with the transtive deps.
Related
I am writing a CLI framework in Clojure called OneCLI. The main center piece of this framework is a function called go! which parses the command line, environment variables, and config files "for you" and runs one of several different user provided functions based on what was provided in those inputs.
Typically, go! is called from the -main function of the user's calling Clojure program. I use my own library, for example, in another "uberjar" style app called zic. The function go! calls System/exit as part of its run, passing it an exit code that comes from the result of the user provided function. This works great "in production", but it also means that I can't run the zic.cli/-main function from the REPL, as whenever I do it calls System/exit and the REPL exits.
Before you ask, running it from the REPL while developing on a raspberry pi avoids the expensive 45 seconds it takes to run lein uberjar/1 minute 30 seconds to run clj -X:depstar uberjar :jar ....
My question is: Is there some var or value I can check as part of Clojure's standard library that tells my OneCLI code whether it's running from the REPL or if it's running from a JAR?
Such a variable would enable me in OneCLI to detect that we're running from a REPL so that it can avoid calling System/exit.
Instead of trying to have one function that magically detects what environment you're running from, it's quite simple to just have two functions that behave differently.
Extract out the shared behavior to a function that is not part of -main. Call it run or whatever.
Have -main call that function, and then call System/exit
When you wish to use the program from a repl, call run instead of -main. It will finish normally, and not call System/exit.
I don't know how to detect if you're running at a REPL. I took a quick look through Clojure's launching code (clojure.main), but I didn't see any hooks to detect whether you're in a REPL compared to something run via clojure -m.
If you're using AOT (like you are in zic) then you could check whether any of the "REPL" variables (*1, *2, *3, and *e) are bound.
;; returns true in a REPL and `clojure -m`, and
;; returns false in an AOT jar file run with java -jar
(bound? #'*1)
This solves your question as it was asked, but I don't love this "magical" mechanism of guessing the programmer's intent. It might work for your use case (given I think AOT saves on startup time, and CLI tools probably want to start quickly), but none of the projects I work on use AOT at all.
Another option to solve your problem in the clojure -m case as well would be to require developers to explicitly opt out of the "exit on completion" behaviour. One way to do that could be to use a property.
(defn maybe-exit [exit-code]
(cond
(= (System/getProperty "onecli.oncompletion") "remain") (System/exit exit-code)
(= exit-code 0) nil
:else (throw (ex-info "Command completed unsuccessfully" {:exit-code exit-code}))))
Using this code, in a development environment you can add
:jvm-opts ["-Donecli.oncompletion=remain"]
to your deps.edn or project.clj file, but leave it out when running "in production". This has the advantage of being more explicit, but the cost is that developers have to be more explicit.
This is an interesting question because it's usually dreadful to put JVM shutdown into a library, but on the other hand a "real app" involves lots of boilerplate that would be great to share... such as hiding the jar's splash gif at the right time, or (re)opening a Windows terminal if the app wants stdio.
Your uberjar will contain clojure.main, so it is quite possible (and useful) to run the REPL in your uberjar (java -cp my-whole-app.jar clojure.main). Therefore, "detecting" clues on the classpath might not help.
Instead, manage JVM-shutdown work in the -main in the namespace that your jar's manifest declares as its Main-Class. That is: if you run it as java -jar my-whole-app.jar, then it should shut everything down properly.
But I do not always want -main to shut everything down, you say. Then you need two -mains. Make a second -main in a different namespace. Let the jar's Main-Class -main do absolutely nothing but (1) delegate to the second main and (2) shut down the JVM at the end. When you're in the REPL, invoke the second -main, the one that won't clobber the JVM. You can factor out most of each -main into a library. If you went "full framework" you could even make the framework own the uberjarring process and the Main-Class.
Every Java JAR file must have the file META-INF/MANIFEST.MF
added. If it isn't present, you cannot be running in a (normal) JAR file. While you could fool this detector by putting a bogus file on the classpath (i.e. in ./resources, for example), it is a reliable way of detecting a normal JAR file.
Problem:
Dependency JAR files are sometimes sloppy and will pollute the classpath with their own META-INF/MANIFEST.MF files, so the presence of any random META-INF/MANIFEST.MF is not enough to determine the answer in the presence of "noise" files. So, you need to check for the existence of your own specific META-INF/MANIFEST.MF file. This is easy to do if you know the Maven values for ArtifactId and GroupId.
In a Leiningen project, the first line of project.clj looks like
(defproject demo-grp/demo-art "0.1.0-SNAPSHOT"
for a group ID of demo-grp and an artifact ID of demo-art. If your file looks like this:
(defproject demo "0.1.0-SNAPSHOT"
then both the group ID and artifact ID will be demo. Your particular MANIFEST.MF will look like
> cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: Leiningen 2.9.1
Built-By: alan
Build-Jdk: 15
Leiningen-Project-ArtifactId: demo-art
Leiningen-Project-GroupId: demo-grp
Leiningen-Project-Version: 0.1.0-SNAPSHOT
Main-Class: demo.core
Set up a function using the to ID strings to detect the presence of your particular project MANIFEST.MF:
(ns demo.core
(:require [clojure.java.io :as io])
(:gen-class))
(def ArtifactId "demo-art")
(def GroupId "demo-grp")
(defn jar-file? []
(let [re-ArtifactId (re-pattern (str ".*ArtifactId.*" ArtifactId))
re-GroupId (re-pattern (str ".*GroupId.*" GroupId))
manifest (slurp (io/resource "META-INF/MANIFEST.MF"))
f1 (re-find re-ArtifactId manifest)
f2 (re-find re-GroupId manifest)
found? (boolean (and f1 f2))]
found?))
(defn -main []
(println "main - enter")
(println "Detected JAR file: " (jar-file?))
)
You can now test the code:
~/expr/demo > lein clean ; lein run
main - enter
Detected JAR file: false
~/expr/demo > lein clean ; lein uberjar
Compiling demo.core
Created /home/alan/expr/demo/target/uberjar/demo-art-0.1.0-SNAPSHOT.jar
Created /home/alan/expr/demo/target/uberjar/demo-art-0.1.0-SNAPSHOT-standalone.jar
~/expr/demo > java -jar /home/alan/expr/demo/target/uberjar/demo-art-0.1.0-SNAPSHOT-standalone.jar
main - enter
Detected JAR file: true
Example of "noise" JAR file: If we do a lein clean; lein run, and add a line to our main program
(println (slurp (io/resource "META-INF/MANIFEST.MF")))
we get out:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: jenkins
Created-By: Apache Maven 3.2.5
Build-Jdk: 1.8.0_111
I have no idea where this is coming from to get on the CLASSPATH.
P.S. for Leiningen JAR files
When using lein to build a JAR file, it always places a copy of the project.clj file at the location:
META-INF/leiningen/demo-grp/demo-art/project.clj
so you could also use this file's presence/absence as a detector.
Update
OK, it looks like the the MANIFEST.MF file is highly dependent on your build tool. See
https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html
https://www.baeldung.com/java-jar-manifest
So, your choices appear to be:
For lein, you can use the above technique.
You could use the REPL trick of *1 from the other answer.
You could always have your build tool include a custom key-value pair in the manifest and then detect that.
Update #2
An alternate answer, and perhaps easier, is to use the lein-environ plugin and environ library (you need both) to detect the environment (assuming you are using lein to create your REPL). Your project.clj should look like:
:dependencies [
[clojure.java-time "0.3.2"]
[environ "1.2.0"]
[org.clojure/clojure "1.10.2-alpha1"]
[prismatic/schema "1.1.12"]
[tupelo "21.01.05"]
]
:plugins [[com.jakemccrary/lein-test-refresh "0.24.1"]
[lein-ancient "0.6.15"]
[lein-codox "0.10.7"]
[lein-environ "1.2.0"]
]
and you need a profiles.clj:
{:dev {:env {:env-mode "dev"}}
:test {:env {:env-mode "test"}}
:prod {:env {:env-mode "prod"}}}
and a namespace demo.config like:
(ns demo.config
(:require
[environ.core :as environ]
))
(def ^:dynamic *env-mode* (environ/env :env-mode))
(println " *env-mode* => " *env-mode*)
And then you get results like:
*env-mode* => dev ; for `lein run`
*env-mode* => test ; for `lein test`
*env-mode* => nil ; from `java -jar ...`
You need to type:
lein with-profile :prod run
to produce
*env-mode* => prod
clojure version: 1.8.0
leiningen version: 2.7.1
jdk version: 1.8.0_101
When I require a library, say reagent(has added in the project dependencies), in the lein repl:
user=> (require '[reagent.core :as r])
nil
The output is nil, which I think it means success. But when I use the r,say (r/atom 3), the repl throw an error says:
CompilerException java.lang.RuntimeException: Unable to resolve symbol: r in
this context, compiling: (/private/var/folders/_y/n3ym4ftj2ld9tl471g_kcv_00000gn/T
/form-init1002540725014588615.clj:1:4923)
That seems strange.
Anyone has some idea?
By the way, I can require java and clojure library.
Probably you are trying to use ClojureScript library: reagent within the Clojure REPL. Finding the cause to error is not that useful since Clojure and ClojureScript are suppose to run in very different environments, JVM and JavaScript respectively. But same attempt will succeed in ClojureScript context.
As a test, create a ClojureScript project based on figwheel template.
lein new figwheel rtest
cd rtest
Add the regent dependency in project.clj
:dependencies [[org.clojure/clojure "1.8.0"]
[reagent "0.6.0"] ; only add this line
Run the project
rlwrap lein figwheel
You will be connected to the browser repl automatically. Otherwise browse to http://localhost:3449/index.html to get connected.
Now you can retry what you did.
cljs.user=> (require '[reagent.core :as r])
nil
cljs.user=> (type r/render-component)
#object[Function "function Function() { [native code] }"]
Suppose that I have implemented a few functions for some personal calculation at work. I'd like to build a .jar (uberjar) that my colleagues would use too in a REPL, like:
megacorpcalcs.core=> (+ 2 2)
4
megacorpcalcs.core=> (salary 8 0.4)
666$
What code should I type for a REPL to start when the .jar launches?
EDIT: after your comments I've split this answer into 2
1. Running your uberjar with a REPL
Create your uberjar, and start it with:
java -cp /path/to/your/application-X.Y.Z-standalone.jar clojure.main -i #your_application/foo.clj -r
I had to add the -i parameter and point it to one of my clj files in order to get any of my classes in the project to actually load in the repl. There may be a better way to do this, but I haven't found it yet. Without it, you get a standard clojure repl but your application isn't loaded.
Note, you need the # symbol so that it loads from the jar file relative to the classpath (i.e from root of jar).
This should start a repl which you can change namespace and run your application functions in.
Additionally, you can install rlwrap and prepend the java command with it so you can use history and arrow keys sanely.
2. Embedding a REPL server in your application to connect to from another client
You can embed your own repl on startup of your application (e.g. a simple main that just starts a repl instance), and then your users can run your jar file, and separately connect to it with their choice of tool (cider-jack-in, 'lein repl connect ...')
The simple version of this is:
(start-server :port 7890 :handler cider-nrepl-handler)
Substitute the port you want, see below for the appropriate namespaces to import.
Here is a more complete example:
(ns your-app.server
(:gen-class)
(:require [cider.nrepl :refer (cider-nrepl-handler)]
[clojure.tools.nrepl.server :refer [start-server]]))
(def repl-server (atom nil))
(defn create-nrepl-server!
[repl-port]
(println (format "starting nrepl server on port %d" repl-port))
(reset! repl-server (start-server :port repl-port :handler cider-nrepl-handler)))
(defn -main []
;; ...
(let [repl-port 7890]
(create-nrepl-server! repl-port)
(spit ".nrepl-port" repl-port)))
You'll need the following in your project.clj file
:plugins [[cider/cider-nrepl "0.10.0"]] ;; or whatever version you prefer
:dependencies [[org.clojure/tools.nrepl "0.2.12"]]
Once connected to your custom repl, standard rules apply, just change namespace and call your functions.
As exercise to gain experience with ClojureScript I am writing a LightTable Plugin and I find no way to successfully use any standard library, I read the official documentation and even updated it to reflect latest changes regarding paths etc.. I followed this video and read the whole thread on the google group trying the proposed solutions, even working with the latest github source without luck.
I tried including core.async or cljs.http (I know the embedded nodejs alternative, just as example) following the proposed workflow by Irakli on the Google discussion. Simplest possible scenario:
$ lein version
Leiningen 2.5.0 on Java 1.7.0_55 Java HotSpot(TM) 64-Bit Server VM (Mac OS X 10.9.5) and LT latest (0.7.2)
$ lein new lt-plugin sample
plugin project.clj->
(defproject sample "0.0.1"
:dependencies [[org.clojure/clojure "1.5.1"]
[cljs-http "0.1.20"]
])
core file
(ns lt.plugins.sample
(:require [lt.object :as object]
[lt.objs.tabs :as tabs]
[lt.objs.command :as cmd]
[cljs-http.client :as http]
)
(:require-macros [lt.macros :refer [defui behavior]]))
(defn get-users
""
[]
(let [response (http/get "https://api.github.com/users" {:with-credentials? false})]
(prn (:status response))
(prn (map :login (:body response))))) ; evaluated correctly
(get-users) ; loads of errors like
WARNING: Referred var clojure.string/split does not exist at line 1 file:/Users/jaime/.m2/repository/noencore/noencore/0.1.16/noencore-0.1.16.jar!/no/en/core.cljs
I run lein deps, save, reload behaviours, restart, refresh plugin lists... all possible combinations tried, with the plugin folder within ~/Library/Application Support/LightTable/plugins or outside.
Should I download the jars and put them manually into a lib folder? I guess lein deps is not working as I expect
Yes currently seems that Cljs native or Cljx for that matter, doesn't resonate well with the LightTable UI.
Trying https://github.com/swannodette/om/wiki/Basic-Tutorial you'll find that it doesn't take much. You can create a LT keybinding to open browser tab, navigate to project folder index.html and make another for reloading (as autoreload is a work in progress I think). Then another tab with the Cljs file while you have the cljsbuild auto running, refresh browser and changes should be witnessed.
I try to get started with ClojureScript using the chestnut leiningen template which combines piggyback, figwheel and weasel. After upgrading my leiningen installation to 2.5.0, I can start the clojure repl, but after issuing the recommended run and browser-repl commands, I run into a cryptic error. There seems to be a core.async issue as well, which I don't know whether it's related.
chestnut-borked.server=> (run)
2014-10-07 12:38:06.506:INFO:oejs.Server:jetty-7.6.13.v20130916
2014-10-07 12:38:06.545:INFO:oejs.AbstractConnector:Started SelectChannelConnector#0.0.0.0:10555
Starting figwheel.
Starting web server on port 10555 .
#<Server org.eclipse.jetty.server.Server#6cdd377c>
Compiling ClojureScript.
Figwheel: Starting server at http://localhost:3449
Figwheel: Serving files from '(dev-resources|resources)/public'
Compiling "resources/public/js/app.js" from ["src/cljs"]...
WARNING: Use of undeclared Var cljs.core.async/do-alts at line 62 file:/home/schauer /.m2/repository/org/clojure/core.async/0.1.278.0-76b25b-alpha/core.async-0.1.278.0-76b25b-alpha.jar!/cljs/core/async/impl/ioc_helpers.cljs
WARNING: Bad method signature in protocol implementation impl/Handler lock-id at line 214 file:/home/schauer/.m2/repository/org/clojure/core.async/0.1.278.0-76b25b-alpha/core.async-0.1.278.0-76b25b-alpha.jar!/cljs/core/async.cljs
WARNING: Use of undeclared Var cljs.core.async.impl.protocols/lock-id at line 217 file:/home/schauer/.m2/repository/org/clojure/core.async/0.1.278.0-76b25b-alpha/core.async-0.1.278.0-76b25b-alpha.jar!/cljs/core/async.cljs
WARNING: Use of undeclared Var chestnut-borked.dev/put! at line 14 src/cljs/chestnut_borked/dev.cljs
[... some warnings removed after first answer ...]
WARNING: Bad method signature in protocol implementation impl/Handler lock-id at line 214 resources/public/js/out/cljs/core/async.cljs
WARNING: Use of undeclared Var cljs.core.async.impl.protocols/lock-id at line 217 resources/public/js/out/cljs/core/async.cljs
Successfully compiled "resources/public/js/app.js" in 21.377 seconds.
notifying browser that file changed: /js/app.js
notifying browser that file changed: /js/out/goog/deps.js
notifying browser that file changed: /js/out/chestnut_borked/core.js
notifying browser that file changed: /js/out/chestnut_borked/dev.js
Besides from the warnings, so far, so good -- Jetty seems to have started successfully. However, when I try to start the browser-repl, I run into an error and the connection seems to be broken:
chestnut-borked.server=> (browser-repl)
WARNING: Bad method signature in protocol implementation impl/Handler lock-id at line 214 file:/home/schauer/.m2/repository/org/clojure/core.async/0.1.278.0-76b25b-alpha/core.async-0.1.278.0-76b25b-alpha.jar!/cljs/core/async.cljs
ArityException Wrong number of args (0) passed to: compiler/with-core-cljs clojure.lang.AFn.throwArity (AFn.java:429)
chestnut-borked.server=> (browser-repl)
java.io.IOException: No client connected to Websocket
at weasel.repl.server$send_BANG_.invoke(server.clj:25)
at weasel.repl.websocket$send_for_eval_BANG_.invoke(websocket.clj:130)
at weasel.repl.websocket$websocket_eval.invoke(websocket.clj:109)
at weasel.repl.websocket.WebsocketEnv._evaluate(websocket.clj:34)
at cljs.repl$evaluate_form.invoke(repl.clj:113)
at cemerick.piggieback$cljs_eval$fn__5152.invoke(piggieback.clj:115)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
[...]
UPDATE: After the input from lnmx, it's becoming clear that weasel isn't functioning properly. If I take a look at the JS elements that the browser sees, the dev script apparently doesn't get loaded and neither is the repl.js from weasel, although there are goog.addDependency calls for them in app.js.
Chestnut 0.5.0 has been released now. It contains an updated ClojureScript which should fix the issue with Weasel (the browser-connected REPL), as well as several other improvements.
I had some success with chestnut 0.5.0, but some changes were needed. I am new to Clojure so I may be missing something -- anyway, here's what I found:
It looks like the README file for chestnut describes the usage of version 0.5.0, but that version is not available on clojars as of today.
So, per the README, I installed from a local copy:
git clone https://github.com/plexus/chestnut.git
cd chestnut
lein install
...and created a new project:
lein new chestnut tree
Attempting to compile the cljs with lein cljsbuild once produced the Bad method signature warning related to lock-id. So, I started by adding the latest core.async to project.clj under :dependencies
[org.clojure/core.async "0.1.346.0-17112a-alpha"]
Then there were some errors related to undefined core.async functions, so I fixed the requires in src/cljs/tree/core.cljs:
(ns tree.core
(:require [tree.dev :refer [is-dev?]]
[cljs.core.async :refer [chan <!]]
[om.core :as om :include-macros true]
[om.dom :as dom :include-macros true])
(:require-macros [cljs.core.async.macros :refer [go alt!]]))
and src/cljs/tree/dev.cljs:
(ns tree.dev
(:require [figwheel.client :as figwheel :include-macros true]
[cljs.core.async :refer [put!]]
[weasel.repl :as weasel]))
The next issue is that tree.dev needs a reference to the re-render-ch owned by tree.core. So I wrapped the "dev mode" setup into a function called from tree.core (src/cljs/tree/core.cljs):
(defonce re-render-ch (chan))
(when is-dev?
(tree.dev/setup re-render-ch))
...and implemented in tree.dev (src/cljs/tree/dev.cljs):
(def is-dev? (.contains (.. js/document -body -classList) "is-dev"))
(defn setup [re-render-ch]
(when is-dev?
(enable-console-print!)
(figwheel/watch-and-reload
:websocket-url "ws://localhost:3449/figwheel-ws"
:jsload-callback (fn []
(println "reloaded")
(put! re-render-ch true)))
(weasel/connect "ws://localhost:9001" :verbose true)))
With those changes, I can start lein repl, (run) and (browser-repl) OK.
During (run) I get this error:
ArityException Wrong number of args (0) passed to: compiler/with-core-cljs
(not sure where this is coming from). However, if I edit tree/src/cljs/tree/core.cljs and add
(reset! app-state {:text "Hello There?"})
the change is compiled automatically and shows up in the browser shortly after I save the file.
Per the comment, this still doesn't fix the browser-repl. For that I had to get a local copy of weasel, and hack src/clj/weasel/repl/websocket.clj ~line 88:
- (cmp/with-core-cljs)
+ (cmp/with-core-cljs {} (fn [] (println "foo")))
It seems to be related to an API change in the cljs compiler. With that, I can (browser-repl) without any warnings, and (do (js/alert "Hello world!") 42) produces an alert in the browser.