This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-20
Channels
- # admin-announcements (2)
- # beginners (38)
- # boot (12)
- # business (2)
- # cbus (2)
- # cider (8)
- # cljs-dev (32)
- # clojure (154)
- # clojure-brasil (43)
- # clojure-czech (3)
- # clojure-dev (5)
- # clojure-germany (1)
- # clojure-japan (2)
- # clojure-nl (2)
- # clojure-poland (9)
- # clojure-russia (29)
- # clojure-sg (12)
- # clojurescript (147)
- # clojurex (22)
- # community-development (2)
- # cursive (8)
- # events (3)
- # ldnclj (30)
- # ldnproclodo (1)
- # leiningen (1)
- # luminus (34)
- # off-topic (6)
- # om (255)
- # re-frame (1)
- # reagent (22)
- # rum (2)
- # yada (1)
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
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.
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.
should be this bit here https://github.com/luminus-framework/luminus-template/blob/64ccbbde0aa50917f1c40211385b897290c288d2/src/leiningen/new/luminus/core/src/middleware.clj#L47
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
Awesome. We just added Luminus pretty recently, and I'm definitely still learning the ins and outs.
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.
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.