uberjar-ed program using plumbing library above 0.3.4 throws exception

Question

uberjar-ed program using plumbing library above 0.3.4 throws exception

ktsujister opened this issue 10 years ago · comments

Hi,

I found this issue where uberjar-ed program using plumbing library above 0.3.4 throws exception.

Below is the minimal sample to reproduce this issue.

;; project.clj
(defproject plumbing-uberjar-issue "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.6.0"]
                 [prismatic/plumbing "0.3.5"]]
  :main ^:skip-aot plumbing-uberjar-issue.core
  :target-path "target/%s"
  :profiles {:uberjar {:aot :all}})

;;  core.clj
(ns plumbing-uberjar-issue.core
 (:require [plumbing.core :refer [fnk sum] :as p]
            [plumbing.graph :as graph])
  (:gen-class))

(def stats-graph
  "A graph specifying the same computation as 'stats'"
  {:n  (fnk [xs]   (count xs))
   :m  (fnk [xs n] (/ (sum identity xs) n))
   :m2 (fnk [xs n] (/ (sum #(* % %) xs) n))
   :v  (fnk [m m2] (- m2 (* m m)))})

(def stats-eager (graph/eager-compile stats-graph))

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  (println "Hello, World!"))

then execute below in shell.

$ lein uberjar
$ java -jar target/uberjar/plumbing-uberjar-issue-0.1.0-SNAPSHOT-standalone.jar

Below is the exception message that I'm getting.
I tried release 0.3.4, 0.3.5, and current-master, but they all fail the same way.

Exception in thread "main" java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:270)
        at clojure.lang.RT.loadClassForName(RT.java:2093)
        at clojure.lang.RT.load(RT.java:430)
        at clojure.lang.RT.load(RT.java:411)
        at clojure.core$load$fn__5066.invoke(core.clj:5641)
        at clojure.core$load.doInvoke(core.clj:5640)
        at clojure.lang.RestFn.invoke(RestFn.java:408)
        at clojure.lang.Var.invoke(Var.java:379)
        at plumbing_uberjar_issue.core.<clinit>(Unknown Source)
Caused by: java.lang.RuntimeException: No such var: schema.core/fn, compiling:(NO_SOURCE_PATH:0:0)
        at clojure.lang.Compiler.analyze(Compiler.java:6464)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3665)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3719)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6646)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6100)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6632)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6100)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6632)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
        at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6100)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6632)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
        at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217)
        at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.analyze(Compiler.java:6406)
        at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782)
        at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217)
        at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846)
        at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
        at clojure.lang.Compiler.analyze(Compiler.java:6445)
        at clojure.lang.Compiler.eval(Compiler.java:6700)
        at clojure.lang.Compiler.eval(Compiler.java:6666)
        at clojure.core$eval.invoke(core.clj:2927)
        at plumbing.graph.positional$eval_bound.invoke(positional.clj:48)
        at plumbing.graph.positional$positional_flat_compile.invoke(positional.clj:88)
        at plumbing.graph$eager_compile.invoke(graph.clj:122)
        at plumbing_uberjar_issue.core__init.load(Unknown Source)
        at plumbing_uberjar_issue.core__init.<clinit>(Unknown Source)
        ... 10 more
Caused by: java.lang.RuntimeException: No such var: schema.core/fn
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.Compiler.resolveIn(Compiler.java:6914)
        at clojure.lang.Compiler.resolve(Compiler.java:6884)
        at clojure.lang.Compiler.analyzeSymbol(Compiler.java:6845)
        at clojure.lang.Compiler.analyze(Compiler.java:6427)
        ... 59 more

Kei Tsuji · Answer 1 · Fri Nov 14 2014 13:45:28 GMT+0800 (China Standard Time)

below is the output of lein version.

Leiningen 2.5.0 on Java 1.8.0_25 Java HotSpot(TM) 64-Bit Server VM
lein version  6.75s user 0.56s system 194% cpu 3.758 total

Jason Wolfe · Answer 2 · Mon Nov 17 2014 10:37:47 GMT+0800 (China Standard Time)

Thanks for the detailed report. I can reproduce locally, but don't have much experience with AOT compilation so I'm not really sure what's going on here.

I suspect it's something to do with this:
https://github.com/Prismatic/schema/blob/master/src/cljx/schema/core.cljx#L1064
but I'm not sure how else to have a namespace that both uses extend-protocol and defines it's own version of fn.

My guess is that uberjar will work fine without AOT compilation. Do you have any suggestions for how to resolve the issue? Did this work on previous versions of plumbing, and if so, what's the latest working version you know of? Thanks again.

Kei Tsuji · Answer 3 · Mon Nov 17 2014 18:24:44 GMT+0800 (China Standard Time)

The latest working version was 0.3.3.
I don't have suggestion for the fix at the moment...

Kei Tsuji · Answer 4 · Thu Nov 20 2014 13:28:11 GMT+0800 (China Standard Time)

I suspect it's something to do with this:
https://github.com/Prismatic/schema/blob/master/src/cljx/schema/core.cljx#L1064
but I'm not sure how else to have a namespace that both uses extend-protocol and defines it's own version of fn.

I'm not sure of better way to workaround that issue, so I upvoted CLJ-1195 for now...

Jason Wolfe · Answer 5 · Thu Nov 20 2014 13:47:32 GMT+0800 (China Standard Time)

Great, thanks! FYI, I think it should be a one-character fix (' to `), if
you feel like making a patch it might speed things along.

On Wed, Nov 19, 2014 at 9:28 PM, Kei Tsuji notifications@github.com wrote:

I suspect it's something to do with this:

https://github.com/Prismatic/schema/blob/master/src/cljx/schema/core.cljx#L1064
but I'm not sure how else to have a namespace that both uses
extend-protocol and defines it's own version of fn.

I'm not sure of better way to workaround that issue, so I upvoted CLJ-1195
for now...

—
Reply to this email directly or view it on GitHub
#74 (comment).

Tom Crayford · Answer 6 · Sun Nov 23 2014 04:55:57 GMT+0800 (China Standard Time)

thought I might poke my head in here and say that http://dev.clojure.org/jira/browse/CLJ-1591 will likely affect AOT compiled programs with update until it's fixed, just to head off any other issues that might get reported

Jason Wolfe · Answer 7 · Sun Nov 23 2014 07:04:13 GMT+0800 (China Standard Time)

Thanks for the heads up!

On Sat, Nov 22, 2014 at 12:55 PM, Tom Crayford notifications@github.com
wrote:

thought I might poke my head in here and say that
http://dev.clojure.org/jira/browse/CLJ-1591 will likely affect AOT
compiled programs with update until it's fixed, just to head off any
other issues that might get reported

—
Reply to this email directly or view it on GitHub
#74 (comment).

David Jarvis · Answer 8 · Fri Dec 05 2014 10:10:34 GMT+0800 (China Standard Time)

Just wanted to add another +1 to this issue as it's affecting us as well; we're okay just holding our version at 0.3.3 for now but it'd be great to see a fix.

Jason Wolfe · Answer 9 · Fri Dec 05 2014 10:25:25 GMT+0800 (China Standard Time)

I suppose for now this could be worked around by moving the extend-protocol calls to another ns. Will see if I can get to that soon. Upvotes (or a patch) for http://dev.clojure.org/jira/browse/CLJ-1195 would also be appreciated.

Jason Wolfe · Answer 10 · Mon Dec 15 2014 08:35:11 GMT+0800 (China Standard Time)

Gotcha. I'll see what I can come up with over the break -- thanks for
bearing with us.

On Thu, Dec 4, 2014 at 6:10 PM, Ursa americanus kermodei <
notifications@github.com> wrote:

Just wanted to add another +1 to this issue as it's affecting us as well;
we're okay just holding our version at 0.3.3 for now but it'd be great to
see a fix.

—
Reply to this email directly or view it on GitHub
#74 (comment).

Jason Wolfe · Answer 11 · Mon Dec 22 2014 11:45:44 GMT+0800 (China Standard Time)

Just submitted a fix to Clojure:

http://dev.clojure.org/jira/browse/CLJ-1195

Please vote for it if you like.

Unfortunately, I don't think this will provide any immediate help since even if merged for 1.7, we'll want to keep schema and plumbing backwards-compatible for awhile. Still thinking about workarounds for the interim.

Dave Della Costa · Answer 12 · Tue Feb 17 2015 16:16:49 GMT+0800 (China Standard Time)

+1...interested in workaround as soon as that comes. Added my vote on Jira for CLJ-1195.

Jason Wolfe · Answer 13 · Wed Feb 18 2015 02:22:25 GMT+0800 (China Standard Time)

I've tried a couple things here, but nothing satisfactory yet. seems like
it may be possible by using clojure.tools.macro to bind fn to the proper
thing under the exclusion, or by moving the extends to a different ns
(perhaps with a little macro magic).

On Tue, Feb 17, 2015 at 12:16 AM, Dave Della Costa <notifications@github.com

wrote:

+1...interested in workaround as soon as that comes. Added my vote on Jira
for CLJ-1195.

—
Reply to this email directly or view it on GitHub
#74 (comment).

Martin Raison · Answer 14 · Thu Apr 23 2015 06:46:55 GMT+0800 (China Standard Time)

If I patch clojure with CLJ-1195, is it supposed to solve this issue or are further changes to prismatic and/or schema still required? AOT is a pretty big use-case, unfortunately, and I cannot afford to drop it.

Jason Wolfe · Answer 15 · Thu Apr 23 2015 07:20:52 GMT+0800 (China Standard Time)

We don't use AOT so I can't state definitively, but I believe that a small additional change to schema will be required:

add fn to the list of exclusions in the ns declaration of schema.core
fully qualify references to fn to clojure.core/fn in core.cljx
remove the ns-unmap line just before fn is defined in core.cljx.

Unfortunately, I don't see a way to make this change that won't break clients without CLJ-1195. Suggestions? Or if you're willing to help set it up we could potentially maintain a separate branch / release for now. Thoughts?

Thanks!

Juan A. Ruz · Answer 16 · Tue Apr 28 2015 20:19:11 GMT+0800 (China Standard Time)

Hi @w01fe ,
here having same issue as @martinraison :(
Did anyone try the trick commented above?

To get it working can you confirm here the required steps:

Apply these changes in my prismatic/schema fork
fork prismatic/plumbing and connect it to my forked schema dep

Thanks!

Jason Wolfe · Answer 17 · Wed Apr 29 2015 06:10:46 GMT+0800 (China Standard Time)

@tangrammer Yep, I believe those should be the full steps. Are you having issues lein installing schema or just plumbing ?

Juan A. Ruz · Answer 18 · Wed Apr 29 2015 19:41:59 GMT+0800 (China Standard Time)

Hi Jason again!

Trying to follow again your steps I got an error when using my modified&&installed prismatic/schema updated fork

user=> (require '[schema.core :as s])

CompilerException java.lang.RuntimeException: Unable to resolve symbol: fn in this context, compiling:(schema/core.clj:172:1)

This is my only commit that I had to do to current prismatic/schema
tangrammer/schema@0f5d7cc

This commit only reflects step one: add fn to the list of exclusions in the ns declaration of schema.core

Second step fully qualify references to fn to clojure.core/fn in core.cljx seems to be done in prismatic/schema master

Then:
rm -rf ~/.m2/repository/tangrammer/schema
cd schema
lein clean
lein cljx once

Rewriting src/cljx to target/generated/src/clj (clj) with features #{clj} and 0 transformations.
Rewriting src/cljx to target/generated/src/cljs (cljs) with features #{cljs} and 1 transformations.
Rewriting test/cljx to target/generated/test/clj (clj) with features #{clj} and 0 transformations.
Rewriting test/cljx to target/generated/test/cljs (cljs) with features #{cljs} and 1 transformations.

lein install

Created /Users/tangrammer/git/tangrammer/schema/target/schema-0.4.3-SNAPSHOT.jar
Wrote /Users/tangrammer/git/tangrammer/schema/pom.xml
Installed jar and pom into local repo.

lein try tangrammer/schema "0.4.3-SNAPSHOT"

nREPL server started on port 58753 on host 127.0.0.1 - nrepl://127.0.0.1:58753
REPL-y 0.3.5, nREPL 0.2.5
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (require '[schema.core :as s])

CompilerException java.lang.RuntimeException: Unable to resolve symbol: fn in this context, compiling:(schema/core.clj:172:1)

in my schema/target/generated/src/clj/schema/core.clj line 172 is this code

(extend-protocol Schema
        Class

  (walker [this]
    (let [class-walker (if-let [more-schema (utils/class-schema this)]
                         ;; do extra validation for records and such
                         (subschema-walker more-schema)
                         identity)]
      (clojure.core/fn [x]
        (or (when       (not (instance? this x))



                  (macros/validation-error this x (list 'instance? this (utils/value-name x))))
            (class-walker x)))))
  (explain [this]
    (if-let [more-schema (utils/class-schema this)]
      (explain more-schema)
            (symbol (.getName ^Class this))            )))

Am I doing it right?

Thanks again
Juan

Jason Wolfe · Answer 19 · Thu Apr 30 2015 00:43:08 GMT+0800 (China Standard Time)

Hi Juan,

This looks like the reason we're not making this change in the core library
yet -- extend-protocol had a bug which I believe is fixed in the latest 1.7
beta. Are you using that?

Cheers,
Jason

On Wed, Apr 29, 2015 at 4:42 AM, tangrammer notifications@github.com
wrote:

Hi Jason again!

Trying to follow again your steps I got an error when using my
modified&&installed prismatic/schema updated fork

user=> (require '[schema.core :as s])

CompilerException java.lang.RuntimeException: Unable to resolve symbol: fn in this context, compiling:(schema/core.clj:172:1)

This is my only commit that I had to do to current prismatic/schema
tangrammer/schema@0f5d7cc
tangrammer/schema@0f5d7cc

This commit only reflects step one: add fn to the list of exclusions in
the ns declaration of schema.core

Second step fully qualify references to fn to clojure.core/fn in core.cljx
seems to be done in prismatic/schema master

Then:
rm -rf ~/.m2/repository/tangrammer/schema
cd schema
lein clean
lein cljx once

Rewriting src/cljx to target/generated/src/clj (clj) with features #{clj} and 0 transformations.
Rewriting src/cljx to target/generated/src/cljs (cljs) with features #{cljs} and 1 transformations.
Rewriting test/cljx to target/generated/test/clj (clj) with features #{clj} and 0 transformations.
Rewriting test/cljx to target/generated/test/cljs (cljs) with features #{cljs} and 1 transformations.

lein install

Created /Users/tangrammer/git/tangrammer/schema/target/schema-0.4.3-SNAPSHOT.jar
Wrote /Users/tangrammer/git/tangrammer/schema/pom.xml
Installed jar and pom into local repo.

lein try tangrammer/schema "0.4.3-SNAPSHOT"

nREPL server started on port 58753 on host 127.0.0.1 - nrepl://127.0.0.1:58753
REPL-y 0.3.5, nREPL 0.2.5
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e

user=> (require '[schema.core :as s])

CompilerException java.lang.RuntimeException: Unable to resolve symbol: fn in this context, compiling:(schema/core.clj:172:1)

in my schema/target/generated/src/clj/schema/core.clj line 172 is this code

(extend-protocol Schema
Class

(walker [this]
(let [class-walker (if-let [more-schema (utils/class-schema this)]
;; do extra validation for records and such
(subschema-walker more-schema)
identity)]
(clojure.core/fn [x]
(or (when (not (instance? this x))
              (macros/validation-error this x (list 'instance? this (utils/value-name x))))
        (class-walker x)))))
(explain [this](if-let [more-schema %28utils/class-schema this%29]
%28explain more-schema%29
%28symbol %28.getName ^Class this%29%29)))

Am I doing it right?

Thanks again
Juan

—
Reply to this email directly or view it on GitHub
#74 (comment).

Juan A. Ruz · Answer 20 · Thu Apr 30 2015 17:13:34 GMT+0800 (China Standard Time)

Hi Jason
I'm now using [org.clojure/clojure "1.7.0-beta1"] in schema, plumbing and my project
Although this time I could install schema and plumbing properly I keep the same error in my project when try to use the compiled gen class

tangrammers-MacBook-Pro:my-project tangrammer$ lein repl
...

Compiling my-project.SC
nREPL server started on port 50575 on host 127.0.0.1 - nrepl://127.0.0.1:50575
REPL-y 0.3.5, nREPL 0.2.6
Clojure 1.7.0-beta1
Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13
Type (dev) to start
user=> (require 'my_project.SC)

CompilerException java.lang.RuntimeException: No such var: schema.core/fn, compiling:(/private/var/folders/tc/rmdq9ttn5l71qqdptppl_1940000gn/T/form-init1869735896197129443.clj:1:1)

Thanks in advance!
Juan

Jason Wolfe · Answer 21 · Fri May 01 2015 02:27:47 GMT+0800 (China Standard Time)

Hi Juan,

Thanks for the update. Can you get any more information on the form that
is causing the errors? Do the tests pass with your changes?

I looked at your fork and it seems like there may still be some unqualified
uses of fn in core.cljx. It's possible that this is causing the
problem, but without knowing where the unqualified reference to fn is
it's hard to say.

-Jason

On Thu, Apr 30, 2015 at 2:13 AM, tangrammer notifications@github.com
wrote:

Hi Jason
I'm now using [org.clojure/clojure "1.7.0-beta1"] in schema, plumbing and
my project
Although this time I could install schema and plumbing properly I keep the
same error in my project when try to use the compiled gen class

tangrammers-MacBook-Pro:my-project tangrammer$ lein repl
...

Compiling my-project.SC
nREPL server started on port 50575 on host 127.0.0.1 - nrepl://127.0.0.1:50575
REPL-y 0.3.5, nREPL 0.2.6
Clojure 1.7.0-beta1
Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13
Type (dev) to start
user=> (require 'my_project.SC)

CompilerException java.lang.RuntimeException: No such var: schema.core/fn, compiling:(/private/var/folders/tc/rmdq9ttn5l71qqdptppl_1940000gn/T/form-init1869735896197129443.clj:1:1)

Thanks in advance!
Juan

—
Reply to this email directly or view it on GitHub
#74 (comment).

Juan A. Ruz · Answer 22 · Fri May 01 2015 05:04:09 GMT+0800 (China Standard Time)

Here again and thanks for your interest!

I pushed my changes to my https://github.com/tangrammer/schema . I didn't find more fn uses in core.cljx but not sure if I had to replace fn in all of schema cljx files

Still having same error :( but no descriptive message yet

tangrammers-MBP:schema tangrammer$ lein test
Rewriting src/cljx to target/generated/src/clj (clj) with features #{clj} and 0 transformations.
Rewriting src/cljx to target/generated/src/cljs (cljs) with features #{cljs} and 1 transformations.
Rewriting test/cljx to target/generated/test/clj (clj) with features #{clj} and 0 transformations.
Rewriting test/cljx to target/generated/test/cljs (cljs) with features #{cljs} and 1 transformations.
Exception in thread "main" java.lang.RuntimeException: Unable to resolve symbol: fn in this context, compiling:(schema/core.clj:172:1)
    at clojure.lang.Compiler.analyze(Compiler.java:6543)
    at clojure.lang.Compiler.analyze(Compiler.java:6485)
    at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3737)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6735)
    at clojure.lang.Compiler.analyze(Compiler.java:6524)
    at clojure.lang.Compiler.analyze(Compiler.java:6485)
    at clojure.lang.Compiler$MapExpr.parse(Compiler.java:3050)
    at clojure.lang.Compiler.analyze(Compiler.java:6532)
    at clojure.lang.Compiler.analyze(Compiler.java:6485)
    at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3791)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6735)
    at clojure.lang.Compiler.analyze(Compiler.java:6524)
    at clojure.lang.Compiler.analyze(Compiler.java:6485)
    at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5861)
    at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5296)
    at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3925)
    at clojure.lang.Compiler.analyzeSeq(Compiler.java:6731)
    at clojure.lang.Compiler.analyze(Compiler.java:6524)
    at clojure.lang.Compiler.eval(Compiler.java:6789)
    at clojure.lang.Compiler.eval(Compiler.java:6782)
    at clojure.lang.Compiler.load(Compiler.java:7237)
    at clojure.lang.RT.loadResourceScript(RT.java:371)
    at clojure.lang.RT.loadResourceScript(RT.java:362)
    at clojure.lang.RT.load(RT.java:446)
    at clojure.lang.RT.load(RT.java:412)
    at clojure.core$load$fn__5427.invoke(core.clj:5862)
    at clojure.core$load.doInvoke(core.clj:5861)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.core$load_one.invoke(core.clj:5667)
    at clojure.core$load_lib$fn__5376.invoke(core.clj:5707)
    at clojure.core$load_lib.doInvoke(core.clj:5706)
    at clojure.lang.RestFn.applyTo(RestFn.java:142)
    at clojure.core$apply.invoke(core.clj:630)
    at clojure.core$load_libs.doInvoke(core.clj:5745)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:630)
    at clojure.core$require.doInvoke(core.clj:5828)
    at clojure.lang.RestFn.invoke(RestFn.java:436)
    at schema.coerce_test$eval182$loading__5319__auto____183.invoke(coerce_test.clj:1)
    at schema.coerce_test$eval182.invoke(coerce_test.clj:1)
    at clojure.lang.Compiler.eval(Compiler.java:6792)
    at clojure.lang.Compiler.eval(Compiler.java:6781)
    at clojure.lang.Compiler.load(Compiler.java:7237)
    at clojure.lang.RT.loadResourceScript(RT.java:371)
    at clojure.lang.RT.loadResourceScript(RT.java:362)
    at clojure.lang.RT.load(RT.java:446)
    at clojure.lang.RT.load(RT.java:412)
    at clojure.core$load$fn__5427.invoke(core.clj:5862)
    at clojure.core$load.doInvoke(core.clj:5861)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.core$load_one.invoke(core.clj:5667)
    at clojure.core$load_lib$fn__5376.invoke(core.clj:5707)
    at clojure.core$load_lib.doInvoke(core.clj:5706)
    at clojure.lang.RestFn.applyTo(RestFn.java:142)
    at clojure.core$apply.invoke(core.clj:630)
    at clojure.core$load_libs.doInvoke(core.clj:5745)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:630)
    at clojure.core$require.doInvoke(core.clj:5828)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:630)
    at user$eval85.invoke(form-init4759133490858548507.clj:1)
    at clojure.lang.Compiler.eval(Compiler.java:6792)
    at clojure.lang.Compiler.eval(Compiler.java:6782)
    at clojure.lang.Compiler.load(Compiler.java:7237)
    at clojure.lang.Compiler.loadFile(Compiler.java:7175)
    at clojure.main$load_script.invoke(main.clj:275)
    at clojure.main$init_opt.invoke(main.clj:280)
    at clojure.main$initialize.invoke(main.clj:308)
    at clojure.main$null_opt.invoke(main.clj:343)
    at clojure.main$main.doInvoke(main.clj:421)
    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.RuntimeException: Unable to resolve symbol: fn in this context
    at clojure.lang.Util.runtimeException(Util.java:221)
    at clojure.lang.Compiler.resolveIn(Compiler.java:7029)
    at clojure.lang.Compiler.resolve(Compiler.java:6973)
    at clojure.lang.Compiler.analyzeSymbol(Compiler.java:6934)
    at clojure.lang.Compiler.analyze(Compiler.java:6506)
    ... 75 more
Tests failed.

Thanks!

Jason Wolfe · Answer 23 · Fri May 01 2015 05:12:26 GMT+0800 (China Standard Time)

Hi Juan,

I apologize, I had mistakenly thought my fix for the bug was merged into Clojure 1.7, but it's still hanging out in JIRA:

http://dev.clojure.org/jira/browse/CLJ-1195?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab#issue-tabs

Until this is merged, I'm not sure how to make headway on this issue except by making your own patched version of Clojure -- and I think it would work with the Schema and Plumbing versions you've created (as mentioned by @martinraison above).

-Jason

Juan A. Ruz · Answer 24 · Fri May 01 2015 05:37:49 GMT+0800 (China Standard Time)

Ok, I'll wait until this fix was merged into clojure.
Thanks for your great support and congratulations about the awesome code that prismatic is building (specially I'm fascinated with graph :) )

Martin Raison · Answer 25 · Fri May 01 2015 05:44:29 GMT+0800 (China Standard Time)

Hi Jason & Juan,

Apologies for not reaching back to you earlier. I just tried patching both Clojure 1.6 (which is the version we're using for the moment) and schema as you suggested (just adding the fn exclusion and removing the unmap as Juan did already). Everything seems to be working now.

I'm not sure what's the best way to go from there, apart from upvoting CLJ-1195 and being patient.

Thanks for being so responsive and keep up with the great work!

Alex Miller · Answer 26 · Fri May 01 2015 21:56:26 GMT+0800 (China Standard Time)

Hey all, thanks for voting on CLJ-1195. In the future, if you have a blocker like this, please feel free to bring it up on the clojure-dev or clojure mailing list or mention it on the ticket itself - I am likely to see any of those. Until today, I wasn't aware this was a blocker for anyone and it wasn't in the 1.7 consideration list. No guarantees on anything but I will discuss it with Rich. I did notice the bump in votes!

Juan A. Ruz · Answer 27 · Sat May 02 2015 03:11:18 GMT+0800 (China Standard Time)

Thanks @puredanger !
I've just voted too :)

Jason Wolfe · Answer 28 · Sat May 02 2015 04:28:42 GMT+0800 (China Standard Time)

Thanks @puredanger -- much appreciated!

Alex Miller · Answer 29 · Fri May 08 2015 21:35:07 GMT+0800 (China Standard Time)

FYI, CLJ-1195 has been approved by Rich for next release of 1.7.

Tim Visher · Answer 30 · Fri May 08 2015 23:29:26 GMT+0800 (China Standard Time)

@puredanger ( ﾟ◡ﾟ)/

Martin Raison · Answer 31 · Sat May 09 2015 01:54:23 GMT+0800 (China Standard Time)

Thanks @puredanger !

Jason Wolfe · Answer 32 · Thu May 14 2015 11:06:52 GMT+0800 (China Standard Time)

Now that there's a (beta) release of Clojure with the patch (thanks again @puredanger !), we can talk about next steps. We don't want to break compatibility with other Clojure versions (which the fix will do), so maybe the best option is for us to release two parallel schema artifacts to Clojars, one for 1.7 (with the fix) and one without. (I don't think any plumbing changes would be required, since you can just override the schema version).

Seem reasonable? Are there simpler ways to make this work that I'm missing? I guess one alternative is to try to condition on the Clojure version in the code, but that seems like it would be really messy (and possibly cause other unforseen problems).

If we go with the above approach, is anyone willing to help set up the parallel builds / maven artifacts? I'm more than willing to maintain a 1.7 branch and cut two releases for the time being, but this is new territory so help (in the form of a PR or otherwise) would be very welcome. Thanks!

Juan A. Ruz · Answer 33 · Wed May 20 2015 05:54:55 GMT+0800 (China Standard Time)

Hi Jackson,
If you could provide some example or extended info of your requirements regarding parallel builds / maven artifacts maybe I can help here :)

Thanks!
Juan

Jason Wolfe · Answer 34 · Wed May 20 2015 06:20:05 GMT+0800 (China Standard Time)

Thanks Juan. I don't have much in the way of requirements, just a setup that makes it as easy as possible to maintain a backwards-compatible master branch, a 1.7 branch consisting of master plus the fix, and an easy way to deploy different artifacts for the two (I suppose this could just be changes to the project file in the 1.7 branch). I'm just not sure how to set this up most effectively, and e.g., whether maven artifact classifiers are the right way to separate the artifacts.

Alex Miller · Answer 35 · Wed May 20 2015 06:28:40 GMT+0800 (China Standard Time)

Maven classifiers are commonly used for this purpose. You might really consider using a version conditional in your code instead and sticking with a single artifact. Instaparse did something like this recently when the internal method they were calling changed in 1.7 - Engelberg/instaparse@14c29fb and there are similar things in other libs that support multiple Clojure versions.

Jason Wolfe · Answer 36 · Thu May 21 2015 12:40:26 GMT+0800 (China Standard Time)

Thanks Alex! We're a bit hesitant about the single-artifact solution because it's a bit hairy -- the conditionals would need to interact with the ns declaration itself, and I don't yet have a good intuitive sense for the kinds of things that will mess with AOT (having never used it myself). But if that doesn't sound problematic to you, maybe we'll give that a try first.

Alex Miller · Answer 37 · Thu May 21 2015 19:28:44 GMT+0800 (China Standard Time)

Sounds hairy! But probably worth trying at least before adopting multiple jars.

On May 20, 2015, at 11:40 PM, Jason Wolfe notifications@github.com wrote:

Thanks Alex! We're a bit hesitant about the single-artifact solution because it's a bit hairy -- the conditionals would need to interact with the ns declaration itself, and I don't yet have a good intuitive sense for the kinds of things that will mess with AOT (having never used it myself). But if that doesn't sound problematic to you, maybe we'll give that a try first.

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

Martin Raison · Answer 38 · Fri May 22 2015 05:13:29 GMT+0800 (China Standard Time)

Hi, I think I have a single-artifact fix based on Alex's suggestion. I'll create a PR in a bit

Jason Wolfe · Answer 39 · Fri May 22 2015 13:36:12 GMT+0800 (China Standard Time)

Thanks @martinraison for the fix (HT @puredanger)! If anyone with AOT issues could try out the latest plumbing with overrides

[prismatic/schema "0.4.3-SNAPSHOT"] and [org.clojure/clojure "1.7.0-RC1"]

and confirm (or deny) a fix, that would be much appreciated. After confirmation, we will cut new schema and plumbing releases ASAP.

Thanks again to everyone for the help with this issue.

Juan A. Ruz · Answer 40 · Fri May 22 2015 17:40:35 GMT+0800 (China Standard Time)

Hi guys!
still getting the same result using this project.clj data

  :exclusions [com.stuartsierra/component org.clojure/clojure prismatic/schema]

:dependencies [
[org.clojure/clojure "1.7.0-RC1"]
[prismatic/plumbing "0.4.3" :exclusions [prismatic/schema]]
[prismatic/schema "0.4.3-SNAPSHOT"]
...
]

1. Caused by java.lang.RuntimeException
   No such var: schema.core/fn

Thanks again!
Juan

Jason Wolfe · Answer 41 · Fri May 22 2015 18:00:38 GMT+0800 (China Standard Time)

@tangrammer Can you please provide a test repo/project and commands so we can reproduce? That would be really helpful. Thanks!

Juan A. Ruz · Answer 42 · Fri May 22 2015 18:25:32 GMT+0800 (China Standard Time)

Working fine now!
PS: just discovered another clojure reference [org.clojure/clojure "1.7.0-alpha4"] that overlapped the good one [org.clojure/clojure "1.7.0-RC1"]
Great to be able to work with graph again!

Jason Wolfe · Answer 43 · Sat May 23 2015 06:50:13 GMT+0800 (China Standard Time)

Thanks everyone for your patience and help! I've just cut two new releases:

[prismatic/schema "0.4.3"]
[prismatic/plumbing "0.4.4"]

(the only change to Plumbing is to bump the schema dependency). Please reopen and let us know if you still have trouble with AOT with these latest versions and [org.clojure/clojure "1.7.0-RC1"].

Martin Raison · Answer 44 · Sat May 23 2015 06:55:40 GMT+0800 (China Standard Time)

Thanks @w01fe for pushing that so fast!