This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-20
Channels
- # announcements (1)
- # beginners (65)
- # calva (16)
- # cider (44)
- # clara (16)
- # clojure (84)
- # clojure-dev (48)
- # clojure-europe (5)
- # clojure-finland (4)
- # clojure-houston (1)
- # clojure-italy (19)
- # clojure-nl (27)
- # clojure-russia (6)
- # clojure-spec (37)
- # clojure-uk (123)
- # clojured (11)
- # clojurescript (21)
- # datomic (40)
- # duct (4)
- # emacs (6)
- # figwheel (4)
- # figwheel-main (5)
- # fulcro (34)
- # jackdaw (8)
- # juxt (117)
- # kaocha (3)
- # klipse (1)
- # leiningen (33)
- # luminus (2)
- # nyc (3)
- # off-topic (29)
- # om (1)
- # pedestal (7)
- # planck (4)
- # re-frame (27)
- # reagent (8)
- # reitit (5)
- # rum (2)
- # shadow-cljs (428)
- # spacemacs (5)
- # tools-deps (15)
- # yada (6)
How do you guys produce an uberjar? uberjar.adoc
says to use bin/onejar
but it doesn't seem like the specified -A:prod
is enough. And bin/uberjar
simply doesn't work: java.io.FileNotFoundException: Could not locate io/dominic/krei/alpha/main__init.class or io/dominic/krei/alpha/main.clj on classpath
Well, using -A:prod
creates a jar that's not runnable since nrepl is missing. Also, there are no generated web resources.
Can you tell me what arguments you pass to bin/onejar
?
Just tried running ../bin/onejar -A:prod:build:prod/build:build/once --args '-m edge.main' project.jar
from main
.
Running java -jar project.jar
still results in Could not locate clojure/tools/namespace/repl__init.class or clojure/tools/namespace/repl.clj on classpath
.
../bin/onejar -A:prod --args '-m edge.main' onejar.jar
is how I produce uberjars btw, but that doesn't factor in cljs/css. But will circle back to that.
Yes, I've seen that documentation. By "what to use" I meant "is there any test project using edge?" 🙂
It may well be that we lack a good example anymore though, vent hasn't been taken into production for example.
OK, just did:
$ ./bin/app acme/test --sass --cljs
$ cd acme.test
$ ../bin/onejar -A:prod --args '-m edge.main' project.jar
$ java -jar project.jar
It failed with:
22:07:31.889 [main] DEBUG io.netty.util.internal.logging.InternalLoggerFactory - Using SLF4J as the default logging framework
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.simontuffs.onejar.Boot.run(Boot.java:342)
at com.simontuffs.onejar.Boot.main(Boot.java:168)
Caused by: clojure.lang.ExceptionInfo: Missing definitions for refs: [:acme.test/index :edge.yada.ig/classpath-name], [:acme.test/assets :edge.yada.ig/resources] {:reason :integrant.core/missing-refs, :config {:acme.test.foo/string "Hello, test!", [:edge.yada.ig/classpath-name :acme.test/index] {:name "index.html"}, [:edge.yada.ig/resources :acme.test/assets] {:path "public/"}, :edge.yada.ig/listener {:handler #integrant.core.Ref{:key :edge.bidi.ig/vhost}, :port 7200}, :edge.bidi.ig/vhost [["" ["" [["/" #integrant.core.Ref{:key [:acme.test/index :edge.yada.ig/classpath-name]}] ["/hello" #integrant.core.Ref{:key :acme.test.foo/string}] ["" #integrant.core.Ref{:key [:acme.test/assets :edge.yada.ig/resources]}]]]]], :edge.kick/builder {:kick.builder/target "target/prod", :kick/sass {:builds [{:id "test", :source "test.scss", :target "public/test.css"}]}, :kick/figwheel-main {:builds [{:id "app", :main acme.test.frontend.main, :output-to "public/frontend.js", :output-dir "public/frontend.out", :asset-path "/frontend.out", :optimizations :advanced}], :figwheel-config {:ring-server-options {:port 3535}}}}}, :missing-refs ([:acme.test/index :edge.yada.ig/classpath-name] [:acme.test/assets :edge.yada.ig/resources])}
at integrant.core$missing_refs_exception.invokeStatic(core.cljc:191)
at integrant.core$missing_refs_exception.invoke(core.cljc:190)
at integrant.core$build.invokeStatic(core.cljc:320)
at integrant.core$build.invoke(core.cljc:303)
at integrant.core$init.invokeStatic(core.cljc:418)
at integrant.core$init.invoke(core.cljc:410)
at integrant.core$init.invokeStatic(core.cljc:415)
at integrant.core$init.invoke(core.cljc:410)
at edge.main$_main.invokeStatic(main.clj:10)
at edge.main$_main.doInvoke(main.clj:8)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.RestFn.applyTo(RestFn.java:132)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.core$apply.invokeStatic(core.clj:665)
at clojure.core$apply.invoke(core.clj:660)
at clojure.main$main_opt.invokeStatic(main.clj:493)
at clojure.main$main_opt.invoke(main.clj:487)
at clojure.main$main.invokeStatic(main.clj:598)
at clojure.main$main.doInvoke(main.clj:561)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:705)
at clojure.main.main(main.java:37)
... 6 more
especially as this is one of the simpler parts of the codebase, and I can see in the failing system that it has those keys.
Why does config.edn
use both [:edge.yada.ig/classpath-name :acme.test/index]
and [:acme.test/index :edge.yada.ig/classpath-name]
?
but yeah, they should match in the template, else integrant will generate different composite keys for them.
Very strange, it's failing to find the edge.yada.ig.resources integrant component when I make them match.
I think it's a recent failure since this part works in my other project that I started earlier.
I think 8a5be082f72fbdb1ec88035b373d9da49820e329
doesn't have this issue since that's what I use in the other project.
As expected. 🙂 Since the issue with with #ig/ref
matching, something must've changed in integrant
, and then the new version must've been used in edge
.
maybe the composite keys method changed and I've been doing it wrong the whole time 🙂
Just checked the versions - I use the same versions of integrant
and aero
. Hmm.
Indeed it works in dev.
Not really novel. 🙂 http://www.catb.org/jargon/html/B/Bohr-bug.html
user=> (ig/composite-keyword [:acme.test/assets :edge.yada.ig/resources])
:integrant.composite/acme.test.assets+edge.yada.ig.resources_10849
user=> (ancestors :integrant.composite/acme.test.assets+edge.yada.ig.resources_10849)
nil
user=> (descendants :integrant.composite/acme.test.assets+edge.yada.ig.resources_10849)
nil
it works for random things like :a/a and :b/b, but not for [:acme.test/index :edge.yada.ig/classpath-name]
user=> (ig/composite-keyword [:a/a :c/c])
:integrant.composite/a.a+c.c_45572
user=> (parents *1)
#{:a/a :c/c}
user=> (ig/composite-keyword [:acme.test/index :edge.yada.ig/classpath-name])
:integrant.composite/acme.test.index+edge.yada.ig.classpath-name_10892
user=> (parents *1)
nil
Okay, if I call (edge.system/system-config {:profile :prod})
then when I do parents I get nil
.
Not sure it that helps, but running a dev repl and (edge.system/system-config {:profile :prod})
doesn't reproduce the error.
From derive
doc: "if [hierarchy] not supplied defaults to, and modifies, the global hierarchy".
Just a wild guess - maybe at some point the global hierarchy is somehow replaced/wiped.
I guess I try calling load-namespaces
now, and see if that clears the global hierarchy anywhere.
user=> (parents (ig/composite-keyword [:acme.test/assets :edge.yada.ig/resources]))
#{:edge.yada.ig/resources :acme.test/assets}
user=> (ig/load-namespaces (edge.system/system-config {:profile :prod}))
21:05:53.810 [main] DEBUG io.netty.util.internal.logging.InternalLoggerFactory - Using SLF4J as the default logging framework
Hayo from edge.yada.ig
(acme.test.foo edge.yada.ig edge.bidi.ig)
user=> (parents (ig/composite-keyword [:acme.test/assets :edge.yada.ig/resources]))
nil
Ideas:
1. Test with manually loading relevant namespaces
2. If that fails as well, maybe try defmethod
or some other ways those keys are used.
this is what the global-hierarchy is after calling load-namespaces: {:parents #:ctx{:return #{:ctx/expr}}, :ancestors #:ctx{:return #{:ctx/expr}}, :descendants #:ctx{:expr #{:ctx/return}}}
That's kinda strange that they used just :ctx
as a namespace there. Seems to have a high chance of colliding with other code.
It's a bug in yada 1.3.0-alpha7. We haven't put that into production yet, so looks like we have a reason not to 🙂