@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

@donyorm yeah agreed

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 leiningen.new.luminus 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 leiningen.new.boot 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

take a look here https://github.com/luminus-framework/luminus-template/blob/master/src/leiningen/new/luminus.clj#L191

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?

s/deployment/implementation

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