lein midje fails with 3.1.2

[nchapon]

When I run lein midje I have this error java.lang.ClassNotFoundException: leiningen.core.main (see error details below) My configuration Leiningen 2.3.2 / lein-midje 3.1.2 / midje 1.5.1 The same configuration works fine with lein-midje 3.1.1

Exception in thread "main" java.lang.ClassNotFoundException: leiningen.core.main, compiling:(/tmp/form-init2091574418830435753.clj:1:2423) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6567) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyze(Compiler.java:6322) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyze(Compiler.java:6322) at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2677) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyze(Compiler.java:6322) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6009) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.analyze(Compiler.java:6322) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5139) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3751) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6558) at clojure.lang.Compiler.analyze(Compiler.java:6361) at clojure.lang.Compiler.eval(Compiler.java:6616) at clojure.lang.Compiler.eval(Compiler.java:6609) at clojure.lang.Compiler.load(Compiler.java:7064) at clojure.lang.Compiler.loadFile(Compiler.java:7020) at clojure.main$load_script.invoke(main.clj:294) at clojure.main$init_opt.invoke(main.clj:299) at clojure.main$initialize.invoke(main.clj:327) at clojure.main$null_opt.invoke(main.clj:362) at clojure.main$main.doInvoke(main.clj:440) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:419) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:532) at clojure.main.main(main.java:37) Caused by: java.lang.ClassNotFoundException: leiningen.core.main at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:61) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at clojure.lang.RT.classForName(RT.java:2070) at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:969) at clojure.lang.Compiler$HostExpr.access$400(Compiler.java:747) at clojure.lang.Compiler.macroexpand1(Compiler.java:6499) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6546) ... 36 more Subprocess failed

[bobbyno]

I'm seeing the same failure with the latest midje, 1.6-beta1. This appears to be related to this discussion.

lein-midje 3.1.1 works.

It looks like the leiningen exit semantics patch caused this problem.

[xsc]

Oh man. I'm sorry I introduced that bug, although I don't know why it did not pop up during testing... Anyways, if @marick decides to just revert to the previous semantics, I'm fine with that (I'll find a way to make calls like those in #42 work).

I gave the whole thing another shot with this commit, storing the number of failures in a file, then using leiningen.core.main/exit to return the value read from it.

[marick]

I've been weighed under by work and (as usual) by obsessively reworking my Rock Mountain Ruby keynote. I plan to spend this coming weekend on Midje.

On Sep 25, 2013, at 5:49 AM, Yannick Scherer notifications@github.com wrote:

Oh man. I'm sorry I introduced that bug, although I don't know why it did not pop up during testing... Anyways, if @marick decides to just revert to the previous semantics, I'm fine with that (I'll find a way to make calls like those in #42 work).

I gave the whole thing another shot with this commit, storing the number of failures in a file, then using leiningen.core.main/exit to return the value read from it.

— Reply to this email directly or view it on GitHub.

---

Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo

[marick]

I'm sufficiently clueless about git (never sat down and learned it properly) and sufficiently tired that I've managed to mess up my git repo. If anyone can produce a pull request that puts the state back at 1dca969543a5a1d9d32eab0fa2d1c9c0386e69e1, I'd be much obliged.

Sigh.

Otherwise, I'll try to work on this over the weekend, but I doubt I'll have time before then.

[bobbyno]

Trying to revert the commits since 1dca9695 with git revert seems to be complicated by the fact that it involves a merged pull request. I tried it, and a git reset HEAD~2 --hard ensued to unravel the damage.

A revert also seems a bit heavy-handed, given the fix to the code is relatively easy.

The problem is in make-load-facts-form in leiningen.midje. I've created a pull request that simply implements the version of make-load-facts-form in 1dca9695, but keeps all of your subsequent 3.1.2 tweaks.

This would get things to a working state and buy some time to consider Yannick's new patch.

[xsc]

No need to consider my patch. When I opened the pull request that introduced the bug I mentioned that the following command would not work (i.e. would not print Leiningen's version), even if no tests fail:

lein do midje, version

So, I went back to the last working commit, took Leiningen in different versions (2.1.3, 2.2.0, 2.3.2), had a look at the sources, thought about it and came to the conclusion that we have to handle two cases:

• normal projects contain :eval-in :subprocess in their project map, resulting in an exception thrown if said subprocess exits with a positive status code - this is what will let the above command work as expected;
• plugin projects contain :eval-in :leiningen in their project map which lets the call to System/exit run inside Leiningen's own process, effectively killing it right there.

So, while my solution (currently included in 3.1.2) should work inside of plugin projects, the original one (restored in #44) was perfect for subprocess-relying ones. I thus propose to generate either System/exit or leiningen.core.main/exit based on the project's :eval-in/:eval-in-leiningen keys, as well as only calling the exit routine if there really were any failures.

[marick]

There's still something weird about this. When I run lein midje on Midje itself, there's a long pause after printing the "All checks succeeded" message and the actual exit (and shell prompt).

Leiningen 2.1.2 on Java 1.6.0_45 Java HotSpot(TM) 64-Bit Server VM

[marick]

Same thing happens with Now running Leiningen 2.3.3 on Java 1.6.0_45 Java HotSpot(TM) 64-Bit Server VM

[marick]

I see the same thing on another Clojure project.

[xsc]

@marick Since the exit routine is not called if no failures are encountered you probably have to wait until Leiningen itself is done. It's a matter of taste, I guess, whether to kill the process right there (preventing potential cleanup actions) or not.

EDIT: Actually, did you want to note that this depends on JRE/Leiningen versions? lein-midje returns instantaneously with Leiningen 2.3.3 on Java 1.7.0_40 Java HotSpot(TM) 64-Bit Server VM and Leiningen 2.3.2 on Java 1.7.0_40 Java HotSpot(TM) 64-Bit Server VM for me.

[marick]

The slow exits happens with Apple's latest version of Java (1.6), so I made it exit immediately in all cases, not just when there's a failure.

https://github.com/marick/lein-midje/blob/master/src/leiningen/midje.clj#L23