Fork me on GitHub

@yogthos so something is calling luminus-boot.core/stop-app and I have no idea what it is. Presumbably it's because the shutdown hook is being called, which means boot must be shutting down the VM. Anything else that could be calling stop-app?


figured it out


Apparently there were no non-daemon threads running so boot just shut the VM down. Adding @(promise) after the call to (start-app) worked. Is that something that should be fixed in luminus?


@yogthos Sorry to be a little spammy, but I'm planning on adding a template to support boot with luminus. I'm thinking to make it as a lein template, since the boot-new project can use lein templates and it will simplify keeping things connected. Does that sound good?


Yeah that seems reasonable to me


Keeping everything in one template will make it easier to maintain in the long term


I guess I need to add the boot option as an argument. I'll have to think about how to do that


I'll keep you updated


I think the promise should love outside the app code since it's bit specific


And sounds good, I can help with the pr once you get it ready


Do you know how lein keeps the app running with all daemon threads? It seems weird to me.


I think I’m missing something basic: I built a CLJS/Reagent/Re-frame app w/Luminus and I’m trying to lein uberjar it so I can deploy, but getting Release versions may not depend upon snapshots. error. There’s a :dev profile dependency on [com.cemerick/piggieback "0.2.2-SNAPSHOT"]. I guess I’m confused about why the :dev profile dependencies are affecting the uberjar build?


I can get it to build with lein with-profile prod uberjar, but I get a bunch of warnings about (Warning: profile :prod not found.) but the uberjar builds and runs just fine


I know this isn’t really a Luminus-specific issue, but I’m hoping someone here can fill my knowledge gap 🙂


@donyorm I think it's the http server that keeps it running, lein runs the main that starts the server and it should keep a thread running listening for connections


It's the same process that happens when you create an uberjar


it's weird that boot doesn't behave the same


@taylor yeah I've seen that happen before, a few things to check would be your lein version and any plugins you might have in your lein profiles


yogthos: thanks, running Leiningen 2.7.1 on Java 1.8.0_112 Java HotSpot(TM) 64-Bit Server VM and cleared out my profiles.clj, but still getting same error from lein uberjar


It seems like a bug in lein, since the dependency should only be in the dev profile


I'm not sure why this only gets triggered in certain cases though


cool, thanks as always for your great support!


no problem and good news is that there’s a non-snapshot version of piggieback now, I’ll update the template to use it


So I've decided to create a +lein and +boot profile, and adding the +lein profile to the default profiles. It should behave the exact same, until you add the +boot profile.


@yogthos Where does luminus define the profiles for the template? I don't see it in the project.clj


take a look at the namespace


each profile has an associated namespace, and that namespace manages the code associated with it


the actual templates are found under resources


you’d want to add a namespace to manage the boot profile and create a boot template file in the resources/leiningen/new/luminus/core folder


@yogthos I found all that. I created a boot namespace and added the files. When I try and run the profile with the +boot profile I get: Unrecognized options: +boot


thanks, I missed that part, I knew there was some place I just had to define it.


has anyone had any luck deploying to openshift? For my clojure demo at work I'm stuck using openshift since that's the new toy the infrastructure team bought. I've seen like 3 blog posts on it and none of them are working for me. I haven't tried the clojure cartridge since I thought if I just uberwar'd my app I'd be good to go deploying the war to a wildfly instance or something. Immutant has pretty good documentation but it's kind of overkill for my little demo so I'm just using jetty


@gdeer81 I've had it on my list since they opened up a free tier... but no, haven't tried yet


Have you seen the tutorial Red Hat put out though?


@pandeiro yeah and I'm trying to go through it and see what I'm missing. It's been a rough week trying to deploy production code and side project demo code and train people on clojure enough to feel like they're contributing


I'm not sure if there are subtle difference between the public openshift and our internal openshift origin platform


@gdeer81 My understanding was that OpenShift was basically a Kubernetes deployment, is that not true?




If so, you should just be able to run an ubjerjar straight up in an official java or java-alpine image container


that's what I thought, I might be over-complicating it. I'm going to try this again as basic as I can


@yogthos what do you think of putting boot options in a seperate function from lein options, but within the same namespace? For most namespaces, I think that may be enough, except for maybe something complicated like db or cljs.


I was thinking it's probably better to manage a single set of options, but have the namespaces that handle them be boot aware


yeah that's what I was thinking


for example if you have #{"+boot" "+cljs"}, then cljs-features function would have an (if (and (contains? options "+boot") (contains? options "+cljs")) ...)


Sounds good, I'll do that. Again, something like immuntant only needs to know about boot for the plugins, in which case I can add a small if-else clause there


I think most of the features are like that


huh. I no longer need the @(promise) clause in the -main function for the server to run. I wonder why that is.


yeah I'm confused why it was needed in the first place


I'll keep an eye on it, something weird is going on.


the openshift saga continues, this was a good guide, i just replaced his github repo with mine in the config, but it seems to be failing on the "mv "$(${HOME}/lein ring uberjar | sed -n 's/^Created \(.*standalone\.jar\)/\1/p')" ${HOME}/app-standalone.jar" part when lein says that ring isn't a task


I think you just need lein uberjar


the lein-ring plugin isn't used anymore


awesome I'm going to fork his whole thing to make a one word change lol


well I tried to create a new image to use but in the end it was just easier to add the plugin to the project.clj. I'm still getting a new mystic error, but oh well


looks like there is a jetty server class that luminus.http-server needs that it can't find for some reason


found a good fork of the image which got the build working. now the deployment is full of yaks because of some odd error about not being able to find lein-cprop :face_with_rolling_eyes:


oh no, it's because its trying to put artifacts in /opt/app-root/src/?/.m2 I don't know why it's putting a question mark in the path and this point I'm too afraid to ask