I’d also like to know this. @eggsyntax did you dig through the history and blame of that file?

It ultimately traces back to commit 6c8eadf (in luminus-template). Comment is 'added exclusion for the default jetty adapter', so there was obviously a specific reason, but no hints on what it was. @yogthos, do you happen to remember July 3 in detail? (I certainly don't) 😉

commit 6c8eadfd7273a6fa22dd0db274ab21bf48dd4c2b
Author: Yogthos <[email protected]>
Date:   Fri Jul 3 02:13:42 2015 -0400

    added exclusion for the default jetty adapter

diff --git a/src/leiningen/new/luminus/core/project.clj b/src/leiningen/new/luminus/core/project.clj
index 3e93609..b573e3b 100644
--- a/src/leiningen/new/luminus/core/project.clj
+++ b/src/leiningen/new/luminus/core/project.clj
@@ -18,7 +18,8 @@
                  [prone "0.8.2"]
                  [org.clojure/tools.nrepl "0.2.10"]
                  [info.sunng/ring-jetty9-adapter "0.8.5"]
-                 [ring "1.4.0-RC2"]
+                 [ring "1.4.0-RC2"
+                  :exclusions [ring/ring-jetty-adapter]]
                  <% ifequal server "jetty" %>[ring-server "0.4.0"]<% endifequal %>
                  <<dependencies>>]

@eggsyntax: I moved to using Immutant as the default http server

so jetty adapter isn’t needed for anything anymore

and when the +jetty option is used then I use the jet adapter that has websocket support

Gotcha, that makes sense, thanks Off the top of your head, do you see a downside to adding it back in (in my project) to support lein-ring (and its handy incremental recompile)?

<shrug> haven't looked into why lein-ring needs it, just noticed that 'lein ring server' won't work without it.

it shouldn’t hurt anything, but I’d stick it in dev dependencies

Totally.

lein run should do same thing as lein ring server btw

since luminus has its own main and it does most of the same stuff

Hmm. It hasn't seemed to pick up changes to the source code, for me, but I expect that traces back to some issue in my project.

Thanks @yogthos, and thanks for Luminus

no prob, glad it’s handy

and the changes reloading should happen via wrap-reload middleware

Cool, I'll look at that first.

should be this bit here https://github.com/luminus-framework/luminus-template/blob/64ccbbde0aa50917f1c40211385b897290c288d2/src/leiningen/new/luminus/core/src/middleware.clj#L47

and that’s how lein-ring does it as well

:thumbsup:

another thing I recommend is using the nrepl, I tend to just connect the editor to the project when it starts up and then I can reload functions and inspect stuff easily as it run

should start up automatically in dev mode on port 7000

Awesome. We just added Luminus pretty recently, and I'm definitely still learning the ins and outs.

let me know how it goes, feedback always helps make it better

:thumbsup:

So far, it's been a pleasure. Adding it to an existing project was pretty straightforward, and -- since we're also pretty new to Clojure itself, and using a lot of unfamiliar technologies -- knowing that someone has integrated key parts of the stack in a solid, thoughtful way has made our lives a lot easier.

Also we've really appreciated that someone has taken time to think carefully about the best choices for (for example) authentication libraries has saved us time. We don't have any unusual auth needs, and we've got tons of other stuff to focus on, so whether or not you've made the exact choices we would if we were starting from scratch doesn't matter too much at this point. It's nice knowing that someone with more knowledge (and who's made all the same decisions we would have in the cases where we had already done that) has made a good, solid choice and included it.

sounds like it’s working as intended then

that was the main motivation for starting the project actually, I found it rather frustrating having to find all the bits and put them together in a nice way when I started out

the whole approach of preferring libraries over frameworks is nice when you know what the libraries are, but it raises the barrier to entry quite a bit

Yeah, for sure. It's fun to do for the things that relate closely to what your project is about, but for tangential stuff it can be a hassle. And the nice thing is that you've made it quite easy to swap those choices out if our needs change. I don't think we would have been willing to use a more traditional framework that locks you into its choices more, especially given how rapidly the clj/s landscape is evolving.

Oh, one minor suggestion -- the documentation is really excellent, which was also a good motivation, but I found myself referring back to the Luminus 2.0 blog post quite a few times. Might be worth folding some of the stuff in that post back into the front page of the documentation, especially the list of default libraries.

oh that’s a good idea

I’ll make an issue for it on the project so I don’t forget