JS lookups are a bit erratic. I haven’t quite figured out a pattern to it.

@U0ETXRFEW after you said that it was erratic I closed and reopened Vs-code, and jacked-in, and now it seems to work XD I don't know what the problem was but a reload fixed things for me

Funny. I should try restart as well, maybe. 😃

thanks!

Thanks! That works swimmingly!

Oh, that’s awesome to know!

My deps.edn looks like this

{:paths ["src/main" "src/test"]
 :aliases {:watch
           {:main-opts ["-m" "shadow.cljs.devtools.cli"
                        "watch" ":app"]}
           :dev-local
           {:extra-deps {com.datomic/dev-local {:local/root "local_jars/dev-local/dev-local.jar"}}}}}

{:deps true
 :nrepl {:port 8777}
 :builds {:app {:target :browser
                :modules [...]
                :output-dir "resources/public/js/compiled"
                :asset-path "/js/compiled"
                :dev {:compiler-options {:closure-defines {re-frame.trace.trace-enabled? true}}}
                :release [...]
                :devtools {:http-root "resources/public"
                           :http-port 8700
                           :preloads [devtools.preload day8.re-frame-10x.preload]}}}}

When I then try to start a REPL via Calva, using deps.edn, then starting with the aliases :watch and dev-local, results in the error above. Looks like some deps from Google, which should come with the Closure Compiler Collection are not in my classpath…? :thinking_face:

The full stacktrace looks like this:

NoClassDefFoundError com/google/common/collect/Streams
        com.google.javascript.jscomp.deps.DependencyInfo$Require.asSymbolList (DependencyInfo.java:60)
        com.google.javascript.jscomp.deps.DependencyInfo$Base.getRequiredSymbols (DependencyInfo.java:163)
        com.google.javascript.jscomp.Compiler.findModulesFromInput (Compiler.java:1914)
        com.google.javascript.jscomp.Compiler.findModulesFromEntryPoints (Compiler.java:1870)
        com.google.javascript.jscomp.Compiler.parseInputs (Compiler.java:1679)
        com.google.javascript.jscomp.Compiler.parseForCompilationInternal (Compiler.java:954)
        com.google.javascript.jscomp.Compiler.lambda$parseForCompilation$4 (Compiler.java:937)
        com.google.javascript.jscomp.CompilerExecutor.runInCompilerThread (CompilerExecutor.java:129)
        com.google.javascript.jscomp.Compiler.runInCompilerThread (Compiler.java:843)
        com.google.javascript.jscomp.Compiler.parseForCompilation (Compiler.java:935)
        com.google.javascript.jscomp.Compiler.compile (Compiler.java:693)
        jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (NativeMethodAccessorImpl.java:-2)
Caused by:
ClassNotFoundException com.google.common.collect.Streams
        jdk.internal.loader.BuiltinClassLoader.loadClass (BuiltinClassLoader.java:606)
        jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass (ClassLoaders.java:168)
        java.lang.ClassLoader.loadClass (ClassLoader.java:522)
        com.google.javascript.jscomp.deps.DependencyInfo$Require.asSymbolList (DependencyInfo.java:60)
        com.google.javascript.jscomp.deps.DependencyInfo$Base.getRequiredSymbols (DependencyInfo.java:163)

Does anyone have any ideas on this problem? Would great to solve this 🙂 Essentially, this is a re-frame project with deps.edn and a backend written in Clojure, starting an http server as an API.

I don’t see shadow-cljs in the dependencies of your deps.edn. Could that be the problem?

Nope, of course it is in my configuration, I just did not want to spam that lot 😉 here are some of my deps, the list is quite long in the original project

{:paths ["src/main" "src/test"]
 :deps {[...]
        org.clojure/clojure {:mvn/version "1.10.2"}
        org.clojure/clojurescript {:mvn/version "1.10.773"}
        re-frame/re-frame {:mvn/version "1.1.2"}
        reagent/reagent {:mvn/version "1.0.0"}
        ring-cors/ring-cors {:mvn/version "0.1.13"}
        ring-middleware-format/ring-middleware-format {:mvn/version "0.7.4"}
        ring/ring-mock {:mvn/version "0.4.0"}
        ring/ring {:mvn/version "1.9.0"}
        ring/ring-defaults {:mvn/version "0.3.2"}
        thheller/shadow-cljs {:mvn/version "2.11.18"}}
 :aliases {:watch
           {:main-opts ["-m" "shadow.cljs.devtools.cli"
                        "watch" ":app"]}
           :dev-local
           {:extra-deps {com.datomic/dev-local {:local/root "local_jars/dev-local/dev-local.jar"}}}}}

When I use the workaround described in your docs to use two separate workspaces, the project works as expected (except for the fact that I have to use two windows, but that is still better than messing around with Cursive)

maybe I build a minimal example tomorrow and paste it in the github issue and this thread, so that you can better see it on your machine. Remote debugging can be very difficult 🙂

Indeed. A minimal example will be super!

Hm… My minimal example works as expected and as described with your solution above… I used my own project and removed everything which is not crucial for the example… Well… Now I have to search the root of the problem 😬

That’s the wonderful thing with minimal examples. Haha.

Super happy it works! We should as a minimum document the way to do this. But I also think maybe we can build it in to the deps.edn + shadow-cljs connect sequence….

Ran into some problems out of the gate:

java -jar c:\Users\[REDACTED]\.vscode\extensions\betterthantomorrow.calva-2.0.173-814-connect-without-project-7ab7b6e8\deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.25.8""}}}"  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
Could not find C:\Users\[REDACTED]\.deps.clj\1.10.1.763\ClojureTools\clojure-tools-1.10.1.763.jar
Attempting download from 
Error building classpath. class java.lang.Character cannot be cast to class java.util.Map$Entry (java.lang.Character and java.util.Map$Entry are in module java.base of loader 'bootstrap')
java.lang.ClassCastException: class java.lang.Character cannot be cast to class java.util.Map$Entry (java.lang.Character and java.util.Map$Entry are in module java.base of loader 'bootstrap')
        at clojure.core$key.invokeStatic(core.clj:1567)
        at clojure.core$merge_with$merge_entry__5962.invoke(core.clj:3060)
        at clojure.core$reduce1.invokeStatic(core.clj:944)
        at clojure.core$merge_with$merge2__5964.invoke(core.clj:3066)
        at clojure.lang.ArrayChunk.reduce(ArrayChunk.java:63)
        at clojure.core$reduce1.invokeStatic(core.clj:942)
        at clojure.core$reduce1.invokeStatic(core.clj:934)
        at clojure.core$merge_with.invokeStatic(core.clj:3059)
        at clojure.core$merge_with.doInvoke(core.clj:3051)
        at clojure.lang.RestFn.applyTo(RestFn.java:139)
        at clojure.core$apply.invokeStatic(core.clj:667)
        at clojure.core$apply.invoke(core.clj:660)
        at clojure.tools.deps.alpha$merge_edns.invokeStatic(alpha.clj:142)
        at clojure.tools.deps.alpha$merge_edns.invoke(alpha.clj:139)
        at clojure.tools.deps.alpha.script.make_classpath2$run_core.invokeStatic(make_classpath2.clj:78)
        at clojure.tools.deps.alpha.script.make_classpath2$run_core.invoke(make_classpath2.clj:57)
        at clojure.tools.deps.alpha.script.make_classpath2$run.invokeStatic(make_classpath2.clj:119)
        at clojure.tools.deps.alpha.script.make_classpath2$run.invoke(make_classpath2.clj:113)
        at clojure.tools.deps.alpha.script.make_classpath2$_main.invokeStatic(make_classpath2.clj:169)
        at clojure.tools.deps.alpha.script.make_classpath2$_main.doInvoke(make_classpath2.clj:140)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.lang.Var.applyTo(Var.java:705)
        at clojure.core$apply.invokeStatic(core.clj:665)
        at clojure.main$main_opt.invokeStatic(main.clj:514)
        at clojure.main$main_opt.invoke(main.clj:510)
        at clojure.main$main.invokeStatic(main.clj:664)
        at clojure.main$main.doInvoke(main.clj:616)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at clojure.lang.Var.applyTo(Var.java:705)
        at clojure.main.main(main.java:40)
Jack-in process exited. Status: 1

Version: 1.53.1 (user setup)
Commit: 5d424b828ada08e1eb9f95d6cb41120234ef57c7
Date: 2021-02-08T23:29:42.785Z
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Windows_NT x64 10.0.21313

This was invoked using the "Fire up a 'Getting Started' REPL" in a new Code Window, so with a new workspace and no existing project.

Interesting. What's your JDK version?

❯ java -version
openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.1+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.1+9, mixed mode, sharing)

This version of Calva is working in a workspace where I already have projects, so it's possible that it is brought on because it was a new workspace without predefined projects. Uncertain about that.

Thanks for helping out testing! It looks like the error @UUDGHH2J1 ran into as well yesterday. Probably to do with that your username contains a space or two. I'm guessing your other projects are not using deps.edn, because this fails with the currently released Calva as well.

@U0ETXRFEW, no space in my user name. 😕 But you are correct about not using deps.edn. The other projects I have right now are Lein based.

No spaces, huh? Not good. Then the problem is deeper. We have a long sad story with quoting the jack-in command line on Windows...

@U0ETXRFEW, yeah, I think I ran into that trying to get Reveal to work. We eventually figured out the escaping which allowed me to modify jvm-opts for reveal, but it wasn't pleasant. This could be because you're using cmd.exe to launch? PowerShell is probably better for Windows users and your sanity anyway. VS Code suggests that it requires Windows 7. PowerShell 2 is integrated for Windows 7. So at a minimum, you should be able to rely on leveraging PowerShell to begin processes and it would likely https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows#escaping-quotes.

I’ve been using powershell and new powershell and everything. Always some Windows setup that doesn’t work. I thought I had nailed it this time, since it worked for all Windows testers.

The good part here is that I can reproduce the error on my VirtualBox Windows.

And I can still jack in to a deps.edn project, so it’s not clearcut a quoting problem…