How can I control the dependencies of IntelliJ Scratch files?

Question

I have a scratch file using guava collections, and I get some weird errors that I have to assume is due to the editor and the actual run environment assuming different versions of the guava collections:

Exception in thread "main" java.lang.IllegalAccessError: tried to access method com.google.common.collect.Range.<init>(Lcom/google/common/collect/Cut;Lcom/google/common/collect/Cut;)V from class 
com.google.common.collect.Ranges
    at com.google.common.collect.Ranges.create(Ranges.java:80)
    at com.google.common.collect.Ranges.closedOpen(Ranges.java:114)
    at Scratch.main(scratch_2.java:69)

Not that I can actually know that for sure because I also can't figure out how I'm supposed to see which version the scratch file is pulling in. I've removed guava from my project's deps ENTIRELY and the scratch file still works... WHY? Where is the library coming from??? The scratch run config is completely empty of anything that would dictate this:

And yet it still runs just fine. I discovered that if I delete the guava entries from my local ivy cache, it won't run anymore. If I then add guava back to my project's deps, it ends up in my ivy cache again, and then even if I remove guava from the project deps the scratch file is fine again. So does the scratch file just pick a random version or something? The ivy cache, which is at ~/.ivy2/cache/com.google.guava, looks like this:

But there's also that "jars" folder that has a guava-12.0 for some reason:

And again, I have no idea which version is being used, or why the cache has so many different versions of it. Any ideas?

Inauspicious

What is your project type? Do you face the same issue with new simple project? – Conduction

It's an SBT project, dependencies are from maven. In a simple new project, even though IntelliJ shares the scratch files themselves between projects, I don't have access to guava so the scratch file cannot be run. In this new project my scratch works fine (the editor and the runtime use the same library version so my stuff works now!), and removing the dep makes the scratch unrunnable immediately without mucking around in the cache. So it appears my issue the scratch file system is local to this one project. Weird. Thanks for the tip though, at least I can run this thing now! – Inauspicious

Answer 1

One way that proved to be the simplest to me was to select "use classpath of an existing project module" (which has dependencies configured) in the run configuration dialog. This is useful if you want to pull out a piece of functionality from your project to play with in isolation but still use the configured dependencies.

Tyrant

In case this helps someone, you can easily use classpath of a parent project for Kotlin scratch files - kotlinlang.org/docs/tutorials/quick-run.html (see "Use classpath of module" configuration) – Seminarian

Using Java, I get Error: Could not find or load main class Scratch when I do this – Flyaway

This does't solve the problem, but for those looking for a work around to the classpath approach configuration, what I did was, I still keep my scratch.java in it's folder, when its ready, I copy and paste it to the root of the folder I would have used to configure the classpath with. In there it seems to work and find the class in the classpath. I know this is not very practical but I just wanted to comment as it could unblock someone. – Carliecarlile

Answer 2

I had a similar issue in PyCharm that I just fixed - so your mileage may vary here. It terms out that there was a Python virtual environment attached as the default to the project window (I had had multiple projects open in the same window - but evidently the first one became the default).

I dug into the list of interpreters, found the one I wanted and edited its properties, specifically Associate this virtual environment with current project.

I checked that box for the virtualenv that had the libraries I was looking for and this fixed the compilation errors in the editor itself.

Eluvium