This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-10
Channels
- # announcements (14)
- # bangalore-clj (1)
- # beginners (89)
- # calva (166)
- # cider (33)
- # clara (12)
- # clj-kondo (1)
- # cljdoc (8)
- # clojure (101)
- # clojure-austin (1)
- # clojure-colombia (7)
- # clojure-dev (14)
- # clojure-europe (5)
- # clojure-hamburg (10)
- # clojure-italy (9)
- # clojure-nl (31)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojurescript (17)
- # clojutre (3)
- # code-reviews (16)
- # cursive (72)
- # data-science (1)
- # datomic (81)
- # duct (8)
- # emacs (4)
- # figwheel-main (1)
- # graalvm (2)
- # jobs (9)
- # kaocha (21)
- # lambdaisland (2)
- # luminus (4)
- # off-topic (35)
- # re-frame (1)
- # reagent (101)
- # reitit (4)
- # ring-swagger (5)
- # shadow-cljs (17)
- # sql (40)
- # tools-deps (4)
- # vim (28)
Just tried opening a REPL in the dev build using Run with Deps and got this printed in an error window:
java/sql/Timestamp
Cloning:
Checking out: at c830e77ff9b00f1e27b7e21f2393f83261aec61b
Downloading: com/cerner/clara-rules/0.19.1/clara-rules-0.19.1.pom from
Downloading: prismatic/schema/1.1.6/schema-1.1.6.pom from
When you say this appeared in an error window, do you mean a notification, or in the Event Log?
And it looks like this REPL doesn’t execute a main namespace or anything like that, correct? The aliases are just pulling in extra deps + source paths?
Failed to start. I think it opened in the Run tab. Correct -- no main ns, just extra deps/paths.
So I can’t reproduce this, or come up with a plausible explanation for why it might happen. Most of the Clojure bugs related to this were fixed in 1.9.0, but there may be dependencies somewhere provoking this problem. However I can’t see how they could be invoked during the REPL classpath calculation using deps (using lein yes, because of plugins).
Very long shot: do you for some reason have #inst reader macros in your deps.edn files anywhere?
Could you also check your log (Help | Show log in Explorer/Finder) to see if there’s any mention of Timestamp there?
My first attempt did not work. It does appear to calculate the classpath each time I open a REPL using Run with Deps.
Ok, so there’s definitely something in your build somewhere using the s3 wagon. If you can find that and upgrade it, I think that will fix the problem.
And yes, currently it will re-calculate the classpath on each run. I added the caching to project resolution, and I’ll add it to the classpath calculation hopefully in the next build.
Now that the error is gone, I guess something may have updated that dep? I don't explicitly use s3-wagon anywhere. Oh gotcha. I misread the release notes for it.
That’s really weird. Could you have an old s3 repo definition kicking around that you don’t use any more? Perhaps in your Maven settings?
One thing that is suspicious - that error is actually reported as: ERROR - llij.ide.plugins.PluginManager
I’m wondering if that’s actually an IntelliJ thing and nothing to do with deps at all. If you go to Preferences | Plugins | <gear icon> | Manage repositories, do you have anything there? You’ll probably have
which is the Cursive EAP channel - anything else?
I don't have a settings.xml
in my .m2
.
We used to have the Datomic Ions S3 repo in our :mvn/repos
map but got rid of Ions. No :mvn/repos
in any of our projects.
Then that is a total mystery. Something somewhere is trying to use or configure an s3 repo, which is where that error is coming from. I have no idea where it might be though. I guess if things are now working correctly then we can just go with it, and try to figure it out if the problem recurs.
I've also now gotten to a place where the Aliases folder in the Clojure Deps dropdown is gone.
@kenny The aliases box will probably not appear if the project can’t resolve, so that might actually be the same problem. Based on the java/sql/Timestamp
part of the error, that’s because 2019.2 by default uses JDK11. Some Clojure deps aren’t ready for JDK9+ yet, and since the new deps integration (like the lein one) runs some stuff in-process, that can affect it. Unfortunately these error messages are always really obscure and it’s hard to track them down. Are you using s3-wagon-private, for example? If you upgrade that to 1.3.2 this problem should go away, assume that dep is the issue.
One thing that was a bit strange about what I was doing is switching between branches where projects had been removed & added. Not using s3-wagon, to my knowledge.
Ok, there are other deps with this problem, but that’s been the one that has bitten most people.
All our projects run and are deployed with Java 11. That means it's likely coming in from a dev dep, I guess.
The disappearing aliases thing was quite confusing though. Is there a way to show an error message instead?
Maybe. I'll try to reproduce it again. What would make it harder to notice is when switching between branches that have removed modules. It seems like every time I switch a branch I get 1-3 notification boxes which makes noticing error messages a lot harder.
What are the notification boxes? If they’re from Cursive I can try to reduce that or combine them somehow.
Oh, and another one is: > Workspace associated with branch 'platformization' has been restored
Right, IntelliJ does that - basically that means that it stores things like open files, window layout, breakpoints etc per branch, and when you switch it restores them.
Right, unfortunately I can’t change any of that. The only one I can control is the deps refresh one, that you won’t see when I fix auto-import if you have that enabled, but the others are out of my control
In master I have modules: a, b In branch1 I have modules: a, c Module a & b seen in Clojure Deps when in master and modules a and c when in branch1.
No. Modules persist across branches. Sometimes I'll get an error about a module disappearing when switching between branches as well. I can't seem to reproduce the latter right now.
Yeah, thinking about it I can see why that might happen. I’ll think about that and try to fix it.
The actual directory for the module may still exist when switching to a branch without the module (e.g. it contains unversioned files like node_modules) but will not contain a deps.edn.
It must have something to do with Cursive since I can open a REPL in the CLI without getting that exception.
No, I’m going to think about that and see if I can reproduce it and improve the error message.
e.g. I can do this in the CLI
clj -A:dashboard:dev:test
Clojure 1.10.1
user=>
But if I type dashboard,test,dev
in the Run with Deps in Cursive and start I REPL, I get the Timestamp error.Yeah, the way this works is that Cursive runs the project resolution in-process in an isolated classloader, which makes it a lot faster for larger projects. The issue is that the JDK used is always the IntelliJ boot JDK, this was almost never a problem previously, but after JDK9 it’s a issue.
Even weirder is it only happens when I use Run with Deps. If I select Run with IntelliJ project classpath with the above aliases selected, it works.
Can you isolate the dep more by trying those aliases one by one? I guess each one can probably have a lot of deps in it though.
Yeah, run with IntelliJ classpath doesn’t do anything at all to calculate the classpath, because IntelliJ already has it recorded.
But actually running your project with that dep on JDK11 doesn’t have the problem, right?
Actually, thinking about this I’m not sure this makes sense for deps. Lein has this problem because the dev deps run arbitrary code during project resolution via plugins - Deps doesn’t do that.
Well, presumably oz is actually used for something in your project. That project works if you run it e.g. from the command line, right?
If I use the "Run with IntelliJ project classpath" and load a ns uses Oz, it will work.
I think there’s something else going on here, and the more I think about it the more I think it might be something in deps itself that Cursive is doing differently.
I have to step out for a bit, but I’ll be back later and I’ll see if I can repro this issue.