Hey. I wonder how to structure a boot project which has a server, acting as a backend, as well as a CLJS frontend and which also is going to be packaged as a self-contained, standalone jar. I ran into some glitches around directories and classpath: By default, CLJS build end up in /target, I can serve that from Ring+Compojure via compojure.route/files but this directory is (by default) not included in the jar package. If I would want to serve it from resources/public I could use compojure.route/resources and it should be part of the classpath by default and as such also included in the jar. I would however need to change the boot build target directory and would end up with a bit awkward directory structure, as static files would be for example under /resources/css as well as /resources/public/css

Furthermore, for me it's not obvious, at which point and which boot task copies files from /resources to /target in the default setup

oh, I am using / started out with tenzing if that matters (with respect to "defaults" for example)

@nblumoe: things end up in target/ at the end of a “full cycle”. That is either after a watch loop or after termination of boot

@nblumoe: when developing many tasks place things on the classpath so you should actually be able to use compojure.route/resources

@nblumoe: when I do boot production build jar I see the the compiled javascript in the jar

@nblumoe: this will not include your clojure sources though unless they’re in :resource-paths

@nblumoe: You should definitely use resources. Nearly the only time you should access target/`is when you copy the build artifact (jar) somewhere.

https://github.com/Deraen/saapas

You could use sift task to remove undesired files from fileset and classpath when you are building the standalone jar

Or you could have separate standalone or such task which modifies :source-paths and :resource-paths so that unnecessary files aren't included in the first place

@juhoteperi: https://github.com/adzerk-oss/boot-reload/pull/27 Could you take a look at this? I fixed my previous buggy pull request, sorry about that 😱

@mitchelkuijpers: Looks good. Merged & pushed snapshot.

@juhoteperi: Thank you!

@martinklepsch @juhoteperi thanks for your help! got it to work now and have a better understanding I guess. the saapas example app was quite helpful, too!

@juhoteperi rocks! :thumbsup:

indeed @meow !

does boot use anything like profiles? I find leiningen profiles really hard to use

@rickmoynihan: Not really. Same thing can be achieved in other ways though: https://github.com/boot-clj/boot/wiki/Boot-for-Leiningen-Users#profiles-middleware

@martinklepsch: Cool... I completely need profiles in leiningen -- but I find them really hard to use, configure and reason about... something more explicit would be handy

that looks much more explicit -- and far less magic

maybe its enough for us to migrate away from leiningen

@juhoteperi: regarding the resources thing above: jumblerg recently discovered a possible issue with the boot serve task in boot-http

serving from the classpath isn't exactly what we want really

we want to serve output files, which include things that might not be on the classpath (eg. :asset-paths) and not serve things that might be on the classpath but aren't output files (eg. :source-paths)

https://github.com/tailrecursion/boot-jetty is an interesting take on it

specifically here https://github.com/tailrecursion/boot-jetty/blob/master/src/tailrecursion/boot_jetty.clj#L23

he syncs output files into a temp dir

and serves jetty from the filesystem there

this is exactly equivalent to how it would be with a war file or uberjar etc.

Hmh, when not using boot-http or such resources is still the right choice as thats what you want to use in uberjar

@juhoteperi: yes, except that the uberjar will have different things on the classpath than the build environment