I’m having trouble with Boot, it seems like some dependencies aren’t being resolved.

Earls-MacBook-Pro:wingapp earljstsauver$ java -jar target/wingapp.app-0.1.0-SNAPSHOT.jar Exception in thread "main" java.lang.NoClassDefFoundError: clout/core/CompiledRoute

@estsauver: is this an uberjar?

Yah

It looks like from what I can find it might be a resource issue.

estsauver: what do you mean by resource issue?

Only cause I can think of is that you’re using a dependency that’s not added to the uberjar — are you adding dependencies as part of development tasks maybe?

I don’t think I am.

I set dependencies in one place in the set-env

I’m not currently making a distinction between dev dependencies and prod.

can you share your build.boot?

@alandipert: https://gist.github.com/anonymous/f465b63aa600a5cd22b7

@estsauver:

alan@alanputer:/tmp/foop$ java -cp target/wingapp.app-0.1.0-SNAPSHOT.jar clojure.main
Clojure 1.7.0-RC1
user=> clout.core.CompiledRoute       
CompilerException java.lang.ClassNotFoundException: clout.core.CompiledRoute, compiling:(NO_SOURCE_PATH:0:0) 
user=> (require 'clout.core)
nil
user=> clout.core.CompiledRoute
clout.core.CompiledRoute

CompiledRoute is a defrocord in clout.core which doesn't exist until you (require 'clout.core). perhaps you are trying to use CompiledRoute before doing this?

you may also add clout.core to the list of NSes you AOT

i gotta run, hope this helps! back later

@tsdh: BOOT_CLOJURE_VERSION sets the version of clojure that boot will use for the actual bootstrapping (i.e. evaluating your build.boot file), it can't know what :dependencies are without evaling build.boot in clojure, so you can't set the version of clojure the build.boot script will be evaluated in in build.boot itself

@tsdh: things go much smoother currently if you use maven repo for all jar deps

@tsdh: if you install your dependency jars to local maven repo tests should work, unless the java classes severely abuse classloader hierarchy by modifying classloaders it doesn't own etc

@tsdh: you should make your tests such that they perform the setup you need in the test context rather than referring to things in the build.boot context, because the tests will run in a fresh pod each time so they won't have access to the build.boot classloader context

if that makes any sense lol

it looks like gibberish now

@micha I guess I can use (getenv "B_C_V") as dependency version so that I need to declare the right clojure version only in boot.properties.

@micha Sorry, but I don't understand your last statement. Is that meant for the third party lib's JavaCompiler?

Are changes to env (say :resource-paths) effective directly or only inside new pods?

@jeluard: they're effective immediately

they aren't propagated to existing pods, but they will be effective in pods created after the env changes

@jeluard: changes to :source-paths and :resource-paths are even effective immediately in the REPL

i.e. you can remove or add directories from the classpath dynamically at runtime, something you usually can't do

normally you can't remove URLs from a URLClassLoader instance

only add

I only care about adding but this is good to know.

for adding you may want to look at the merge-env! function in boot.core

(merge-env! :source-paths #{"new-src"})

that adds "new-src" to :source-paths without overwriting the existing ones

otherwise you can do like (set-env! :source-paths (fn [old-source-paths] (conj old-source-paths "new-src")))

So if I modify resource-paths in a task defined in my buid.boot (say dev) only sub-tasks creating new pods will see those changes?

it depends where you do it

if you do it before returning the handler it will happen when the pipeline is being constructed

i.e.

(deftask foo []
  (set-env! ...)
  (with-pre-wrap [fs] ...))

that's where i'd do it i think

that will happen before the pipeline is composed

like when you do boot foo bar baz on the command line

what's actually constructed is the expression (boot (foo) (bar) (baz)) in clojure

so when (foo) is evaluated is when the set-env! would happen

in the above example

great! Is it safe to load resources from Thread.currentThread().getContextClassLoader() in this case?

@jeluard: yes, i think so

the only problems arise when loading clojure classes into the parent of that classloader

you should look at boot.pod/add-classpath and friends

those will do the right thing, respecting classloaders marked by boot as being immutable

boot uses dynapath for that

but that's just a convention for marking classloaders with metadata that indicates that they shouldn't be altered

it's not supported at the JVM or Java level

the boot.pod namespace is available in any bot pod

s/bot/boot/

Thanks! I have some trouble reading files from the classpath from a boot task but it does not look related to 'dynamic' env actually. Now that I know what I can expect I will dig more.

I've struggled with a quite weird AOT/uberjar issue while trying to port a leiningen build component based program to boot.

@jeluard: if you have a simple test case i can have a look at it if you want

Have created a repo demonstrating the issue here: https://github.com/ragnard/boot-uberjar-mystery

Have created an issue (https://github.com/boot-clj/boot/issues/227) but if anyone has any insight or want to discuss it I'd be happy to

is suspect it's something related to the aot compilation, protocols and classfile mismatch

@ragge: i'll have a look

@micha: thanks! i'm probably doing something silly somewhere

@ragge: have you looked in the jar yet?

to make sure the things you need are in there?

yes

like any .clj files you may need specifically

from your own project

would I need any .clj in this case? main is aot compiled, the two other namespaces should be transitively compiled too, no?

oh ok, yeah that makes sense

i def have classfiles for all those namespaces

ok cool

i could sort of see this issue happening if the component/Lifecycle protocol classfiles don't match the component/Lifecycle that the TestComponent implements

in that case, when i call start, the TestComponent would not implement the start of the correct interface

even though they're called the same thing

and then start would fallback to the implementation for Object

which is a no-op I believe

i recently fixed a bug with uber task that might be relevant

ah, ok

let me know if you need any help re-producing this (or if it simply works with recent bug fix)

@ragge: https://github.com/boot-clj/boot/issues/211

does that look like it could be a problem?

that particular issue is fixed in master

micha: What do you think about this: https://github.com/adzerk-oss/boot-cljs/commit/23cb2fd21fb39354121e7342a9d01128dad32fed

By checking the clojure-version inside pod I can catch cases where user has added clojure to dependencies using set-env

deraen: that looks perfect

one minor thing is maybe check *clojure-version* instead?

@micha: What is that?

(let [{:keys [major minor]} *clojure-version*]
  (when-not (and (= major 1) (> minor 6))
    (warn "Requires minimum Clojure version 1.7.0")))

it's a dynamic var that has the clojure version parsed into a map

Oh right

this would just help in the case where someone uses this version of boot-cljs with future versions of clojure

@micha: hard to judge, but I can give master a go

@ragge: awesome, thanks!

I also took a stab at implementing asset-path for boot-reload: https://github.com/adzerk-oss/boot-reload/pull/22

@micha: Should work correctly with string compare also, but comparing numbers is better

@micha: can I just clone boot, do a make install and change boot.properties in my project to the master snapshot version?

@juhoteperi: not sure what to do about the major version

maybe (>= major 1) is the right thing there

@ragge: yep

@micha: (when (and (<= major 1) (< minor 7)) ...)

@micha: Or no, that doesn warn with version 0.9 :D

that's the hardest thing in lisp lol

macros are for children

the experts struggle with (< 1 2)

This should do it: (or (< major 1) (and (= major 1) (< minor 7)))

hmm

what about "0.9.0" ?

@micha: That matches the first or branch

oh i see

By the time Clojure hits 2.x I am pretty sure this boot task will have different constraints! Maybe just force major = 1.

right i was thinking in reverse, matching the acceptable versions

@micha: it works using master so something has fixed it

instead of matching the versions to warn about

lol

@micha: thanks for helping me resolve it, will close the issue

@ragge: haha that was easy, awesome!

@micha: next obvious question is when is next release? 😉

@micha: about my issue: it looks related with dynamic env after all. I will work on creating a small test case.

@ragge: i can make one today

@micha: that would be much appreciated! thanks for the great work on boot, I'm enjoying exploring it

@ragge: thanks 🍻

Related to dynamic env: can one of sub-tasks be defined in a source-path a task just added? i.e.

(deftask dev []
  (merge-env! :source-paths #{"src-dev"})
  ; some call to let boot discover my task
  (comp .. (start)))

I'm looking for confirmation that I understand the typical cljs repl workflow using boot. Here is what works for me now:

;; => boot repl -c
;; boot.user=> (start-repl)
;; cljs.user=> (js/alert "This is a test of the emergency broadcasting system.")
;; cljs.user=> (require '[app.core :as app] :reload)
;; cljs.user=> (app/foo 3 4)
;; 7
;; cljs.user=> :cljs/quit
;; boot.user=> (quit)
;; Bye for now!

Not sure how unified mode fits in, which I'm not using.

@jeluard: you need to require the namespace and then eval the expression

otherwise clojure will choke compiling the expression

`

(deftask dev []
  (merge-env! ...)
  (require 'some.namespace)
  (comp ... (eval '(some.namespace/start))))

or someting like that

@meow: unified mode is always on now in boot-cljs, so you're using it i think

Plus I see lots of activity here: https://github.com/adzerk-oss/boot-cljs-repl/pull/18

Ah great thanks

@micha: then I guess I am using unified...

Now, if I add a (defn ...) to my core.cljs file it doesn't get recognized in my repl namespace so it looks like the :reload option isn't working or perhaps I'm still a bit confused by this stuff.

hmm, i'll be back in a while

time to get a truck and move a couch

@micha: I took a look at boot-cljs-repl update and I think boot-cljs-repl should depend at least on tools.nrepl, looks like if any lib in project depends on tools.nrepl it will bring in an old version

deraen: i think maybe :scope "provided" for these issues?

@micha: With scope provided the dependency for cljs-repl is not added to the project?

boot-cljs-repl already has [org.clojure/tools.nrepl "0.2.10" :scope "provided"]. Removing the :scope fixes the problems,.

deraen: oh i see what you mean

deraen: i don't like the idea of boot tasks adding dependencies to your project

but maybe we need to

@micha: I would rather make the tasks warn if user doesn't have necessary deps

User should probably have cljs dependency in the project

right, or we could force the correct versions of the deps

How?

by filtering the project deps before making the pod

and adding our fixed versions to the pod

The problem is that repl doesn't use pods

ah right

yeah the repl is always a special case because of that

still maybe warnings is the right way to go with cljs-repl too

ok be back in a bit

hello again

I'm now hitting this: https://github.com/boot-clj/boot/blob/76980e6b132f46a8b00cecd5fd2713343cc21a49/boot/pod/src/boot/pod.clj#L372

because of "Too many files open"

investigated a bit

and I think there may be a file handle leakage in copy-url

it's happening in uber task

in unpack-jar

i ran strace on my build and saw this pattern:

8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 147
8924  open("/nix/store/c00cymmlb0p05wrr7wq1h11yqqd8i75r-oraclejdk-8u45/jre/lib/content-types.properties", O_RDONLY) = 148
8924  close(148)                        = 0
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/uswitch/mobiles-data-hub/6v2/4naatj/project.clj", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 148
8924  close(148)                        = 0
8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 148
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/uswitch/mobiles-data-hub/6v2/4naatj/META-INF/leiningen/cheshire/cheshire/README.md", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 151
8924  close(151)                        = 0
...

sorry, I'll include a few more lines for the pattern to make more sense:

8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 147
8924  open("/nix/store/c00cymmlb0p05wrr7wq1h11yqqd8i75r-oraclejdk-8u45/jre/lib/content-types.properties", O_RDONLY) = 148
8924  close(148)                        = 0
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/redacted/redacted/6v2/4naatj/project.clj", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 148
8924  close(148)                        = 0
8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 148
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/redacted/redacted/6v2/4naatj/META-INF/leiningen/cheshire/cheshire/README.md", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 151
8924  close(151)                        = 0
8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 151
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/redacted/redacted/6v2/4naatj/META-INF/leiningen/cheshire/cheshire/LICENSE", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 152
8924  close(152)                        = 0
8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 152
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/redacted/redacted/6v2/4naatj/cheshire/core.clj", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 153
8924  close(153)                        = 0
8924  open("/home/ragge/.m2/repository/cheshire/cheshire/5.4.0/cheshire-5.4.0.jar", O_RDONLY) = 153
8924  open("/home/ragge/.boot/cache/tmp/home/ragge/projects/github/redacted/redacted/6v2/4naatj/cheshire/custom.clj", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 154
8924  close(154)                        = 0

this is unpacking the cheshire jar

you can see that the open calls to the jar file has no corresponding close

saturday maybe not best day to get people to star at strace logs...