2.6.0 and ClassNotFound with lein midje

[jsyrjala]

I am not sure if this is lein, lein-midje or midje issue.

I just did lein upgrade and now lein midje fails with this stacktrace when using lein 2.6.0

Everything worked fine with lein 2.5.3.

I am using plugin lein-midje "3.1.3" and clojure 1.8.0

Exception in thread "main" java.lang.ClassNotFoundException: leiningen.core.project$reduce_dep_step, compiling:(/private/var/folders/3g/p3lk84l10ts3jt11dcd719340000gn/T/form-init3118179863086925175.clj:1:9866)
    at clojure.lang.Compiler.load(Compiler.java:7386)
    at clojure.lang.Compiler.loadFile(Compiler.java:7317)
    at clojure.main$load_script.invokeStatic(main.clj:275)
    at clojure.main$init_opt.invokeStatic(main.clj:277)
    at clojure.main$init_opt.invoke(main.clj:277)
    at clojure.main$initialize.invokeStatic(main.clj:308)
    at clojure.main$null_opt.invokeStatic(main.clj:342)
    at clojure.main$null_opt.invoke(main.clj:339)
    at clojure.main$main.invokeStatic(main.clj:421)
    at clojure.main$main.doInvoke(main.clj:384)
    at clojure.lang.RestFn.invoke(RestFn.java:421)
    at clojure.lang.Var.invoke(Var.java:383)
    at clojure.lang.AFn.applyToHelper(AFn.java:156)
    at clojure.lang.Var.applyTo(Var.java:700)
    at clojure.main.main(main.java:37)
Caused by: java.lang.ClassNotFoundException: leiningen.core.project$reduce_dep_step
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:69)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at clojure.lang.DynamicClassLoader.loadClass(DynamicClassLoader.java:77)

[hypirion]

Yeah, I can verify that this breaks for some reason. I'll have a look later today to see if I can figure out the cause.

[theJenix]

If it helps, I get the same problem with a pretty basic compojure app. To reproduce, create a new app using the compojure-app template (see: https://github.com/yogthos/compojure-template) and attempt to run it with "lein ring server-headless". You should see it fail in the same way.

[hypirion]

This is now fixed on master.

Since this breaks many popular plugins, I believe this warrants a bugfix release in and of itself. I'd like to wait roughly half a day, so that other potentially major bugs can be discovered and hopefully be resolved in the same release.

[owengalenjones]

I'm still getting this error on 2.6.1:

vagrant@vagrant-ubuntu-trusty-64:/opt/code/sourcerer/sourcerer$ lein --version;lein run -m sourcerer.migrate/-main migrate
Leiningen 2.6.1 on Java 1.7.0_95 OpenJDK 64-Bit Server VM
Compiling 1 source files to /opt/code/sourcerer/sourcerer/target/classes
Compiling 1 source files to /opt/code/sourcerer/sourcerer/target/classes
Compiling sourcerer.migrate
java.lang.ClassNotFoundException: leiningen.core.project$reduce_dep_step, compiling:(cfg/current.clj:8:9957)
Exception in thread "main" java.lang.ClassNotFoundException: leiningen.core.project$reduce_dep_step, compiling:(cfg/current.clj:8:9957)
    at clojure.lang.Compiler.compile(Compiler.java:7313)
    at clojure.lang.RT.compile(RT.java:398)
    at clojure.lang.RT.load(RT.java:438)
    at clojure.lang.RT.load(RT.java:411)

[hypirion]

I need some more information here to be able to debug this: Is this an issue with a plugin, or is that a pure project that runs lein run on some files that are aot-compiled/java files? (If the project is OSS then that would be even better, but I couldn't find a Clojure one with that name)

Does it work fine if you do lein do javac, compile; lein run -m sourcerer.migrate/-main migrate?

[owengalenjones]

Much apologies, as of today with the exact same setup I had on Monday I'm unable to replicate.

[hypirion]

Oh, no worries; feel free to comment if you hit the issue again.

[sdegler]

I have a plugin that still fails reliably, and it seems to correlate with @owengalenjones 's failure that he listed above. The plugin uses configleaf, and from the output above, I believe that his does too.

[hypirion]

@sdegler If you could get a minimal reproducible case I'd be happy to take a look at it. Is it simply basic use of configleaf that fails?

[pkan]

It is the basic use of configleaf hook functionality that fails. It hooks leiningen.core.main/apply-task, in order to save the project map as a namespace, which is then compiled with the project sources (so that the application's build configuration is available to it at runtime).

Since Leiningen rebinds *print-dup* to true for the last apply-task call, and since configleaf does not bother to set it back to false, the map's metadata ends up printed as well. Leiningen happens to initialize project :plugins and :dependencies with function-valued metadata. These functions come from leiningen.core.project. When the namespace produced by configleaf is compiled, the print-dup / read-eval round trip fails, because leiningen.core.project is no longer in the classpath, and the functions cannot be found.

I tried working around the problem by adding leiningen-core to my project as a dependency, and adding leiningen.core.project to :aot, in front of the stuff that brings in the troubling configleaf namespace. That did not work as expected. I received a

java.lang.RuntimeException: Method code too large!

while compiling the configleaf-produced namespace. This seems to refer to its __init method. The method's bytecode, at 450k, was well over the JVM limit of 64k. Now, this had nothing to do with the questionable use of functions as metadata. It's just that a print-dup'ed project map can easily get too big for the Clojure compiler.

I cannot escape the conclusion that the entire blame for trying to do something unreasonable here lies with configleaf (which hasn't been updated in 4 years). A simple rebinding of *print-dup* and *print-meta* for configleaf.core/output-config-namespace would solve the problem. Personally, I will be dropping configleaf, and writing my own hook for saving the project map; it is only a few lines of code.

[hypirion]

I think this may be resolved again with #2082, which was released with lein 2.7.0. Can someone confirm this?

[technomancy]

I'm going to close this but would be happy to reopen if given a repro case.