Fork me on GitHub
#boot
<
2015-07-30
>
nblumoe09:07:24

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

nblumoe09:07:07

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

nblumoe09:07:29

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

martinklepsch10:07:21

@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

martinklepsch10:07:53

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

martinklepsch11:07:28

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

martinklepsch11:07:31

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

juhoteperi11:07:16

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

juhoteperi11:07:57

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

juhoteperi11:07:37

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

mitchelkuijpers11:07:45

@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 😱

juhoteperi12:07:25

@mitchelkuijpers: Looks good. Merged & pushed snapshot.

mitchelkuijpers12:07:51

@juhoteperi: Thank you!

nblumoe13:07:51

@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!

meow13:07:25

@juhoteperi rocks! 👍

nblumoe13:07:49

indeed @meow !

rickmoynihan14:07:42

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

martinklepsch14:07:40

@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

rickmoynihan14:07:50

@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

rickmoynihan14:07:13

that looks much more explicit -- and far less magic

rickmoynihan14:07:51

maybe its enough for us to migrate away from leiningen

micha14:07:26

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

micha14:07:39

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

micha14:07:16

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)

micha14:07:36

he syncs output files into a temp dir

micha14:07:48

and serves jetty from the filesystem there

micha14:07:20

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

juhoteperi21:07:17

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

micha22:07:41

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