cursive-ide
Can't start REPL with 2025.1-251, can't report error to Cursive
I updated to latest IntelliJ and Cursive and now I get an error when I start my repl in this project:
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at cursive.maven.ArtifactRepositoryManagerFacade.resolveDependency(ArtifactRepositoryManagerFacade.kt:68)
at cursive.deps.shims$shim_classpath_files.invokeStatic(shims.clj:167)
at cursive.deps.shims$shim_classpath_files.invoke(shims.clj:157)
at cursive.deps.shims$deps_clj_shim.invokeStatic(shims.clj:182)
at cursive.deps.shims$deps_clj_shim.doInvoke(shims.clj:173)
at clojure.lang.RestFn.invoke(RestFn.java:428)
at cursive.deps.utils$parse_args.invokeStatic(utils.clj:189)
at cursive.deps.utils$parse_args.invoke(utils.clj:188)
at clojure.lang.Var.invoke(Var.java:395)
at cursive.api.DelayedFn.invoke(DelayedFn.java:41)
at cursive.runner.BaseJvmClojureRunConfiguration.createDepsParameters(ClojureRunnerBase.kt:139)
at cursive.repl.runner.LocalConfiguration$getRunProfileState$2.createDeferredParameters(LocalReplRunConfigurations.kt:121)
at cursive.runner.DeferredCommandLineState.cacheDeferredParameters(Deferred.kt:71)
at cursive.runner.AbstractDeferredRunner$execute$1.run(Deferred.kt:103)
at com.intellij.openapi.progress.impl.CoreProgressManager.startTask(CoreProgressManager.java:497)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.startTask(ProgressManagerImpl.java:118)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressAsynchronously$7(CoreProgressManager.java:548)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:252)
at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$0(ProgressManager.java:98)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$1(CoreProgressManager.java:229)
at com.intellij.platform.diagnostic.telemetry.helpers.TraceKt.use(trace.kt:43)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:228)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$14(CoreProgressManager.java:680)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:755)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:711)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:679)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:77)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:209)
at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:98)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$5(ProgressRunner.java:252)
at com.intellij.openapi.progress.impl.ProgressRunner$ProgressRunnable.run(ProgressRunner.java:513)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$launchTask$18(ProgressRunner.java:478)
at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:102)
at com.intellij.util.concurrency.ChildContext$runInChildContext$1.invoke(propagation.kt:102)
at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:108)
at com.intellij.util.concurrency.ChildContext.runInChildContext(propagation.kt:102)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$launchTask$19(ProgressRunner.java:474)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:735)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:732)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:732)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException: /Users/alex
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update(DefaultTrackingFileManager.java:80)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write(DefaultUpdateCheckManager.java:529)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact(DefaultUpdateCheckManager.java:476)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads(DefaultArtifactResolver.java:636)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:545)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:449)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:243)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:243)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:183)
at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382)
at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368)
at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218)
at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156)
at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138)
at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108)
at org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222)
at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:306)
at org.jetbrains.idea.maven.aether.ArtifactRepositoryManager.lambda$prepareRequests$2(ArtifactRepositoryManager.java:383)
at org.jetbrains.idea.maven.aether.ArtifactRepositoryManager.lambda$runWithRetry$4(ArtifactRepositoryManager.java:602)
at org.jetbrains.idea.maven.aether.RetryProvider$1.retry(RetryProvider.java:22)
at org.jetbrains.idea.maven.aether.ArtifactRepositoryManager.runWithRetry(ArtifactRepositoryManager.java:602)
at org.jetbrains.idea.maven.aether.ArtifactRepositoryManager.prepareRequests(ArtifactRepositoryManager.java:383)
at org.jetbrains.idea.maven.aether.ArtifactRepositoryManager.resolveDependencyAsArtifact(ArtifactRepositoryManager.java:322)
at org.jetbrains.idea.maven.aether.ArtifactRepositoryManager.resolveDependency(ArtifactRepositoryManager.java:278)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
... 45 more
Caused by: java.nio.file.AccessDeniedException: /Users/alex
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:462)
at java.base/java.nio.file.Files.createDirectory(Files.java:700)
at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:808)
at java.base/java.nio.file.Files.createDirectories(Files.java:794)
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update(DefaultTrackingFileManager.java:77)
... 71 more
The deps.edn is:
{:paths ["src"]
:deps
{org.clojure/clojure {:mvn/version "1.12.0"}
org.clojure/core.async {:mvn/version "1.9.808-alpha1"}
io.github.clojure/core.async.flow-monitor {:git/tag "v0.1.0" :git/sha "9d02164"}}}
When I try to report to Cursive in the IDE, that also fails:
Failed to submit exception report:
422 Unprocessable Entity : ErrorResponse(message=Validation Failed, errors=[ErrorItem(resource=Search, field=q, code=invalid, message=The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.)])
Works fine with clj from the command line.
I tried many things to modify the deps.edn, disable plugins (like Copilot which I weirdly see there) etc, clear caches, etc. Could not get the REPL to run so I have for now fallen back to the last 2024 version of IntelliJ and Cursive.
When I try to report to Cursive in the IDE, that also fails:
Ouch, I did some GitHub housekeeping but missed the error report repo, I'll fix that now. I'll check the deps error in the morning.
Any idea why this might be happening? I wonder if IntelliJ 2025.1 runs with different privileges somehow? java.nio.file.AccessDeniedException: /Users/alex
I don’t understand either why it’s trying to access that, or why it can’t.
I assume it is somehow related to the maven local repo, but I don’t think I have anything unusual in how my system is set up.
The repo I was using is now public at https://github.com/puredanger/flow-example if that helps to repro anything - I was just trying to create and run a Clojure REPL there.
I just tried to repro this, and it all works fine for me. It definitely looks like it's something to do with accessing your local maven repo:
Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException: /Users/alex
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update(DefaultTrackingFileManager.java:80)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write(DefaultUpdateCheckManager.java:529)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact(DefaultUpdateCheckManager.java:476)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads(DefaultArtifactResolver.java:636)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:545)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:449)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:243)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:243)
which looks like it's trying to create a directory:
Caused by: java.nio.file.AccessDeniedException: /Users/alex
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:462)
at java.base/java.nio.file.Files.createDirectory(Files.java:700)
at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:808)
at java.base/java.nio.file.Files.createDirectories(Files.java:794)
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update(DefaultTrackingFileManager.java:77)
... 71 more
Unfortunately I don't have a plausible explanation for why this might happen, or why the behaviour would be different between one version of Cursive/IntelliJ to another. None of this code has changed in the last version that I can recall, and all this low-level code is delegated to deps.clj anyway. My best guess would be that the user used to run IntelliJ is different in 2025.1 for some reason? That would be super weird though. I don't think that it could be a difference in the Maven version in IntelliJ, that should all be pulled in by deps.clj in an isolated class loader.
Ran into this exact problem. My issue turned out to be related to the MAVEN_REPOSITORY value being set in ~/Library/Application Support/JetBrains/IdeaIC2025.1/options/path.macros.xml
Mine had:
<macro name="MAVEN_REPOSITORY" value="/Users/keithharper/.m2/repository" />
Should have been:
<macro name="MAVEN_REPOSITORY" value="/Users/keith.harper/.m2/repository" />
I suspect this happened when I switched to a new machine, changed my username, and restored from a backup that had a different username. I wonder if this value just wasn't being used in previous versions of Cursive?
I checked and that file is also out of date for me, matches a much older machine's setup. @keithharper I think your guess is likely correct.
@puredanger Do you have any idea why this worked for you on the command line? Surely it should have broken there too?
I don't understand the question - how would I be using ~/Library/Application Support/JetBrains/IdeaIC2025.1/options/path.macros.xml from the command line?
Oh, my apologies, I misread and thought it was a Maven settings file that was out of date, not an IntelliJ one.