so It seems i have been able to get the app deployed to heroku!! needed to build uberjar but now jetty is giving a 404

@micha what was the design decision around boot always pulling deps?

how do you mean "always pulling deps"?

boot always goes through the process of pulling deps for a project (or at least checking for them) whenever it’s run

is there a way to disable this?

what's the issue you're having?

i mean if you can't have dependencies then you must make an uberjar

im not so much having an issue as it’s a huge ammount of time spent pulling deps for a container every time I want to test a change in build.boot

oh, you can cache the maven stuff

it's documented in the adzerk/boot-clj README i think

basically you set BOOT_LOCAL_REPO to some directory in your container

ok i thought it already cached those

see here https://github.com/adzerk-oss/boot-clj-docker-image#cache-maven-artifacts-at-build-time

yeah i moved all of my compiling to the task that the container runs

the compiled uberjar is throwing a 404 but I can run it in dev?

for docker you can work in layers

so docker can cache things

@micha got the uberjar working (cant quote the ns)

hmm... im not getting any messages from the reload ring middleware when it's reloading namespaces. it's annoying because i can't even see compilation errors either. i was expecting to see them via castra at least but they dont appear there either

i checked the example in the lein new hoplon-castra x generated project but that doesnt have any special setup, just uses (serve :reload true)

@onetom: can you post the boot task

??

(deftask dev
  "Build backends for development."
  []
  (let [nrepl-port 9999]
    (spit ".nrepl-port" nrepl-port)
    (comp (serve :port 3001
                 :reload true
                 :handler 'appboard.api/ring-handler
                 :nrepl {:port nrepl-port})
          (wait))))

(def ring-handler
  (->
    (site #'routes)
    (wrap-defaults api-defaults)
    (wrap-castra
      'our.api 'some-more.api ...)
    (wrap-utf-8)
    (wrap-session
      (node-mongo-session (config :db) "sessions" "xxxxx"))
    (wrap-cors (re-pattern (str "^" (config :frontend-url) "/?$"))
               (re-pattern (str "^" (config :homepage-url) "/?$"))
               (re-pattern (str "^" (config :cockpit-url) "/?$")))))

hmm actually im not seeing any difference when i change :reload to false

https://github.com/ring-clojure/ring/blob/master/ring-devel/src/ring/middleware/reload.clj#L19-L22

it only does the reload when a request is sent

not directly on filesystem change

@onetom would have to ask @pandeiro about it

@onetom Can you try 0.7.1-SNAPSHOT?

@pandeiro: i will try tomorrow, thx!

This was fixed recently

we have actually looked into the patches and i saw u touched something around the reload

Yeah @esp1 contributed that and if it works for you I'll cut a 0.7.1 release

When I do require inside a deftask body I get a class not loaded error, when I do it outside everything works. Is that expected?

@jaen https://github.com/boot-clj/boot/wiki/Run-time-requires-%28within-task-definitions%29

@jaen: not sure if this is what you’re looking for but came to mind reading your question

Well, I haven't read this wiki page, but I'm doing exactly that. Maybe something else is wrong then.

(deftask dev
  "Starts the development environment."
  []

  (require 'scrabble.backend.core)
  (let [system-var (resolve 'scrabble.backend.core/dev-system)]
    (comp
      ...)))

Is what I'm doing, and when I try the same from REPL it seems to resolve

Yet in the task I get

Unable to resolve var: scrabble.backend.core/dev-system in this context

Ok, nevermind, I thought I substituted the var quote for resolved var in the body of the task, which I didn't.

I probably need to wake up or something. Sorry for the bother '

@pandeiro: we have a split frontend/backend setup, so a, we use [jumblerg/ring.middleware.cors "1.0.1"] as shown above b, as your readme suggests, we just use wait instead of watch, unlike the hoplon-castra template shows as a result im just seeing errors, like:

POST  

XMLHttpRequest cannot load . No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' is therefore not allowed access. The response had HTTP status code 500.

it seems that the response with the error message doesnt have the CORS headers, but im not sure at which level is it stripped off i might try to debug it tomorrow with print-foo's middleware support maybe...

@onetom I don't think wait/watch should matter. Are you sure you whitelist all the headers your using with the cors request? That's one possible gotcha.

Has anyone experienced obscenely slow tests using boot-test? My tests run in a fraction of a second via CIDER but take almost a minute when part of a task pipeline with boot-test.

what else are you doing in the pipeline?

also what if you run the tests from the repl

or is that what you're doing with cider, basically?

@micha: Yeah, testing from the repl is what I meant by cider. That's basically instantaneous. The pipeline is (watch) (speak) (test) (repl :server true)

seems pretty normal

are you on java 7 or 8?

Hmm doesn't boot-test run the tests on a fresh pod each time?

java 8

It will be really slow when compared to just reloading one ns and running the tests

Or even when compared to reloading the changed ns (via c.t.n or ns-tracker)

@juhoteperi: Even specifying that tests should be run on specific namespaces is awfully slow

...via boot-test task options

Yeah it will reload all the namespaces where the specific namespace depends on

or not reload, but just load

because boot-test uses completely empty pod each time

Is it this slow for everyone could there be something pathologic with my system? I don't think anyone would use boot-test if this was the norm.

I don't use boot-test for development, only for CI

My code base is tiny and tests take a minute to run

Well, that doesn't sound normal

Used boot test recently with watch and it was super snappy

maybe large fixtures need to be recreated

Does the test namespace require any slow to compile namespaces?

fixtures: It's a datomic in-memory test. Only a single conn is created and all tests are run using with so I doubt that is a major time hog.

slow requires: I'll check

it's starting with a fresh pod each time, remember

so datomic won't survive a reload

nothing is shared from one test run to the next

@micha: Understood. However the fixture loads instantaneous by my perception (so a few hundred ms at most) and is only run once per ns. It might contribute a few seconds in total to the test time but I don't think it accounts for the total time. I'm trying to start a repl to test recompiling dependent namespaces but am having network issues. Will check back later when I get it working.

Hmm, this is weird. When I run the tests fresh in a repl it takes a few seconds. Fine. However, when I put :reload-all in the main test ns and reevaluate the namespace, I get a compiler exception NPE from within core.async