Fork me on GitHub
#boot
<
2016-10-24
>
alandipert15:10:13

@borkdude excellent post!

alandipert15:10:28

using boot-cp and then planck is a cool workflow

dave16:10:58

wow, yeah, that is really cool

dave16:10:19

up until now i've been creating one-off "projects" with a build.boot whenever i want to try a clojurescript library

dave16:10:53

the boot-cp + planck way looks more convenient

tmtwd17:10:23

is there a :jvm-opts like in lein? I was googling over the weekend and couldn’t find anything specific

micha17:10:53

@tmtwd you'd use the environment variable BOOT_JVM_OPTS

tmtwd17:10:05

yes, that’s what I found

tmtwd17:10:18

so I can use that for project specific environment variables?

tmtwd17:10:32

I thought that was more for like your personal boot profile

micha17:10:39

yes, it can go in ./boot.properties

micha17:10:55

it needs to be an environment variable

tmtwd17:10:57

hm ok, I see

micha17:10:05

because the JVM needs to start with the options

tmtwd17:10:11

I tried using that and boot repl wouldn’t start

tmtwd17:10:39

is there a difference between putting it in ./boot.properties vs like normal via export on the CLI?

micha17:10:00

boot reads the properties file from inside the JVM

micha17:10:13

so by that time it's already too late

micha17:10:25

cause the JVM is already started

tmtwd17:10:34

so I need to put it in ./boot.properties?

micha17:10:45

you need to export the environment variable

micha17:10:53

or put it on the command line

micha17:10:11

none of the properties files will help, because the JVM will start before any of them are read

tmtwd17:10:28

hm interesting

tmtwd17:10:49

somehow the env variable I was using was making boot error out

tmtwd17:10:14

I guess I’ll make an issue for it later

danielsz21:10:33

Do we have control on the maven resolution phase? I depend on a snapshot library which doesn't get updated when deploying in production. Not sure why.

micha21:10:16

@danielsz Snapshots are cached in maven. You can do this:

micha21:10:27

(with-call-worker (boot.aether/update-always!))

micha21:10:34

in your build.boot before you add dependencies

micha21:10:00

it doesn't always work because snapshots are complicated

danielsz21:10:40

Oh, that's good to know! If I do boot show -U will this update my deps including snapshots?

micha21:10:44

you can also add :update :always in your repository settings

micha21:10:09

i would just avoid snapshots in production 🙂

danielsz21:10:22

Yes, that is good advice 🙂

micha21:10:23

it's really difficult to get any reliable behavior with them

micha21:10:45

for production i'd go with uberjar probably

micha21:10:55

completely eliminate maven from the equation

danielsz21:10:23

I am building a uberjar, but the build pipeline doesn't update one of the snapshots 🙂

micha21:10:38

i misunderstood

micha21:10:03

that's easier, you should be able to do boot show -U then

danielsz21:10:24

The problem is with the clojurescript libraries. Before I do (uber) I am compiling the cljs, and the cls depends on a snapshot. Catch 22 🙂

micha21:10:47

doing boot show -U should fetch the latest snapshot

micha21:10:02

then after that you should (in theory) be able to build with the latest snapshot

danielsz21:10:55

Cool! Thanks a bunch. Will report here.

micha21:10:14

good luck 🙂

danielsz22:10:02

@micha It worked. You're my hero!

micha22:10:04

@danielsz great!

hlship23:10:53

I’m making good progress, but I’m not quiet sure when it is necessary to commit! the FS. I’m basically adding commit! when files are not readable or correct.

micha23:10:48

@hlship good to hear 🙂 the purpose of commit! is to sync the classpath and underlying filesystem with the fileset object

micha23:10:19

if you add things to the fileset it's similar to having uncommitted changes in git

micha23:10:00

you want to commit before you pass the fileset to the next task usually

micha23:10:32

another way to describe it is that the fileset object is a snapshot of the filesystem at a certain instant in time

micha23:10:52

there can be multiple fileset objects held by different parts of the program

micha23:10:01

but there can be only one filesystem

micha23:10:42

when you call commit! on a fileset object that make the files in the filesystem correspond to the fileset object

micha23:10:28

so you can hold onto a fileset, which is a snapshot, and at some later time you can commit! it, thereby "restoring" the filesystem to the state it was in when that snapshot was made