Fork me on GitHub
#calva
<
2021-09-27
>
mindbender05:09:26

How do I set up Calva to browse java sources?

pez05:09:26

You need java sources installed. I think that up to java 14 it was bundled.

mindbender05:09:28

By install you mean including it in dependency, right?

mindbender05:09:32

And for third party code, does it also mean having associated foo-sources.jar included in dependency?

pez07:09:29

Depending on which java version you have you might need to install java sources manually. And cider-nrepl tries the classpath, so if you have the java sources path in :resource-paths for a Leiningen project, it should work. I don’t think you need to have it declared as a dependency for the docs to work.

manas_marthi12:09:48

I didn't even understand the question..

Pratik16:09:00

I am also having similar problem, for example if I am importing

(java.time.format DateTimeFormatter DateTimeParseException)
then, I can’t navigate to the java DateTimeFormatter code

Pratik16:09:00

how to find if I have java sources installed or not? I am on JDK 15

pez16:09:22

You probably have some jar/zip with the jdk in JAVA_HOME.

Pratik16:09:04

I don’t have a JAVA_HOME variable set….

pez17:09:15

Your Java installation lives somewhere... Maybe there is an option to the java command that can tell you?

Pratik17:09:35

yes, I got a path to the JDK, and it’s in my $PATH, but still can’t peek the definitions for java code

Pratik17:09:30

looks like the extension that I am using(Language Support for Java by RedHat) searches for pom.xml in the project, and doesn’t initialize the project if it doesn’t find it

pez18:09:58

Do you know wether or not the docs are included in the jdk?

Pratik18:09:28

When I create a new java project using the extension command, I am able to go to the java source, so the those docs are included

pez11:09:14

It depends on how the Java extension looks up sources. Maybe it looks them up online?

Pratik15:09:56

Huh, for you does it work without any extension?

Pratik15:09:53

Did you have to setup anything apart from installing JDK and adding it in the $path

pez16:09:39

I’m using jdk12 zulu. I don’t recall when they stopped bundling the docs. Could have been between 14 and 15. Google can probably tell us.

Pratik16:09:54

I installed JDK11 and removed 15, for a moment it started working, then I got some error like Invalid filename <whatever java symbol I click on> and on closing and re-opening I am getting that error only when I am connected to the REPL, else it shows “no relevant symbol” error

pez17:09:08

It is a dynamic feature in Calva so you won't get it unless you have the repl connected. Please file an issue. Looks like a bug to me.

👍 1
Pratik17:09:38

https://github.com/BetterThanTomorrow/calva/issues/1304 added the issue. let me know if any other info is required

👍 2
❤️ 1
bringe03:10:43

@U0HJYDTP1 I added a comment to the issue here that might shed more light on the issue: https://github.com/BetterThanTomorrow/calva/issues/1304#issuecomment-931867787

mmer12:09:34

When loading the current file and its dependencies into the repl, could it be possible to actually list the files that have been loaded?

pez13:09:33

If the load-file op returns with this info, it would be entirely possible.

pez13:09:27

Otherwise, still possible, but would probably best be fixed upstream in Orchard.

flowthing13:09:27

Helping out a colleague with Calva... does Calva support deps.edn + shadow-cljs? I mean, it's an option in the jack-in quick panel, but I haven't been able to get it to work. I've tried what I think is the simplest combination, which is: 1. npx shadow-cljs watch :app 2. Jack in 3. Choose deps.edn + shadow-cljs 4. Choose the correct shadow-cljs build ID I get a dialog saying "Failed staring cljs repl for build: :app. Is the build running and connected?" The build (or the "watch", I guess) is running (step 1), but I don't know what "connected" means. The Calva Connection Log panel only says "Socket closed".

pez14:09:55

Is shadow-cljs configured to use deps? If so try jacking in with only shadow-cljs project type. If it’s a backend using deps.edn and a frontend using shadow.cljs it should be possible to use the deps.edn + shadow.cljs option, but it is tricky to a point where I wonder if maybe it is broken.

pez14:09:34

Also, you shouldn’t mix step 1 there with step 2. Because Jack-in actually runs the step 1 command.

pez14:09:25

Anyway, with some luck you have a project where shadow-cljs is setup to use deps.edn. Then jacking in with shadow-cljs should work.

flowthing14:09:46

shadow-cljs is indeed configured to use deps.edn (at least shadow-cljs.edn has a :deps key).

flowthing14:09:41

Jacking in and selecting shadow-cljs doesn't work, either. This is the last thing that gets printed in the REPL output:

; Starting Jack-in Terminal: npx shadow-cljs -d cider/cider-nrepl:0.26.0 watch :app
And the indicator in the status bar remains in the "Disconnected" state.

flowthing14:09:01

I even tried hooking up tcpflow to inspect the traffic between the server and the client, but there's so much of it that it's hard to glean anything useful out of it.

flowthing14:09:38

It would be helpful to see what the exception is that causes to socket to close.

flowthing14:09:57

If I had to guess, this issue is related to the shadow-cljs nREPL middleware, but I'm not sure, of course.

flowthing14:09:40

In the Terminal tab, I see:

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.8.3"},cider/cider-nrepl {:mvn/version,"0.26.0"}}}' -A:dev -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
But shadow-cljs needs a different middleware (`shadow.cljs.devtools.server.nrepl/middleware`).

flowthing14:09:11

I do have this in .nrepl.edn in the project root:

{:middleware [shadow.cljs.devtools.server.nrepl/middleware]}
But maybe it gets overridden by the --middleware flag?

bringe01:09:23

I haven’t used shadow like this before, but that seems like it might help: https://shadow-cljs.github.io/docs/UsersGuide.html#_embedded_nrepl_server

bringe01:09:08

I’m not sure if it gets overridden though.

bringe01:09:05

You could try starting a repl that also injects that middleware and see if it helps.

bringe01:09:54

You can copy the command easily with the command “Copy Jack-in Command to Clipboard,” then modify it and run it in a terminal and connect Calva to that repl.

wevrem22:09:41

When I attempt the simplest possible thing (not starting a watch but just jacking in and choosing deps.edn + shadow-cljs) which, of course, I would just like “to work”(tm), it doesn’t. The clj repl starts up okay, but when it attempts to start up the cljs repl, I get an error that it can’t find certain shadow api files on the classpath. When I start a watch and a cljs-repl for shadow in separate terminal windows, those work okay, but I’ve never been able to connect to them within Calva/VSC. If I do, it breaks the original clj repl. So far I’ve only been successful with clj repl in Calva, and cljs repls in their own terminal windows.

pez04:09:36

Maybe you need a shadow-cljs dependency declared in deps.edn?

flowthing05:09:57

@U9A1RLFNV That's an excellent tip, thanks! I had already pretty much given up, but I got it to work by defining a custom connect sequence like this (this is obviously project-specific, but):

"name": "MyApp",
                "dependsOn": "User provided",
                "projectType": "deps.edn",
                "cljsType": {
                    "startCode": "(juxt.clip.repl/start)",
                    "connectCode": "(shadow.cljs.devtools.api/nrepl-select :app)"
                }
I then used "Copy Jack-In Command…" and modified the invocation to add the shadow-cljs middleware into the list of middleware:
clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.8.3"},cider/cider-nrepl {:mvn/version,"0.26.0"}}}' -A:dev -m nrepl.cmdline --middleware "[shadow.cljs.devtools.server.nrepl/middleware cider.nrepl/cider-middleware]"
Then "Connect to … in project".

pez06:09:20

Nice! We used to inject Figwheel dependencies but had to stop with that because it interfered with some project’s specific needs. But nrepl middleware we should be able to auto-inject without interfering, I think…

bringe16:09:55

An issue with some details of your solution would be nice, @U4ZDX466T! That way we can track this and add the support to make this scenario work.

flowthing16:09:57

Yeah, I'll try to come up with something.

👍 1
flowthing17:09:22

Although you could maybe argue that this is an nREPL issue, actually.

flowthing17:09:30

Well, I'll let you guys sort it out. 🙂

pez17:09:16

You could also argue that the scenario does work. 😃 We should at the very least document what we have just realized. And we should consider what we could do to make it more convenient and needing less documentation.

flowthing17:09:02

Hmm, it's not only nREPL, actually -- I think there might be a problem in both.

wevrem00:10:21

I tried to do @U4ZDX466T’s workaround, but got a different set of errors. I added dependency to shadow-cljs in deps.edn, as suggested by @U0ETXRFEW, and I’m not getting errors anymore about not finding shadow API’s, now I’m getting an error about Could not initialize class com.google.javascript.jscomp.DiagnosticGroups . This is related to Google Closure compiler, right? but I’m not sure how to resolve it. Maybe this is relevant: I’m using deps.edn for my clojure dependencies, but all the cljs stuff is declared in shadow-cljs.edn file; I’m not using the :deps key in that file.

flowthing09:10:31

It does sound like a Closure thing. I would ask in #shadow-cljs.

flowthing09:10:00

Something might be pulling in a different Closure version than what #shadow-cljs expects.