@micha: i wonder about cells for wrapping the FS states

well, ref-backed cells

how would you use that

also i figured out how to parse json with no external deps other than java 7

and without writing a json parser of course

nashorn ftw 💥

oh sweet

does it perfs?

yeah way faster than starting a pod and doing it with clojure

it's for the binary downloader thing

it has to parse github api responses

hi, in case anyone is interested: https://jarkeeper.com now supports boot projects. See https://jarkeeper.com/hashobject/perun

^ this is awesome 🎉 @juhoteperi boot watch all-jars with partial rebuilds is going to be a thing!

@martinklepsch: Would be useful it dependencies could be passed to pom task

@juhoteperi: why?

@martinklepsch: Would remove one reason for with-env etc.

And instead of using with-env/with-dir it would be possible to select the files using sift include

@juhoteperi: you still want dependencies on classpath for aot though

Yeah but for development the classpath could contain dependencies for all modules

I think the issue with using plain sift would be mostly that you cannot go back to the original fileset so you can pass it to following tasks?

Code review, thoughts, concerns welcome ^^

@micha: GPG PR could also use review, it should be ready now

ok cool

i'm writing up how the loader thing works

forgot to do that in the commit message

^^ updated commit message

👍 Nice enhancements, @micha .

@danielsz: ty

a cool thing about the new binary is that you can run any version of boot with it, back to boot 2.0.0

without needing to use a different binary of course

pre and rc versions are not supported, because some of those were borken

@micha: that sounds great. can head.sh get deleted?

@martinklepsch: we still use head.sh to build boot.sh

and Launch4J to make boot.exe

but we will only have one boot.sh and one boot.exe

we won't need to update those again, hopefully

the loader does so very little, there isn't much that can break with it

i made the loader a java program instead of a shell script because this way it has no external dependencies

other than java 7

@micha: looking at the Makefile I don’t see it being used?

it's in boot/loader/Makdefile i think

ah its in the main makefile

https://github.com/boot-clj/boot/commit/f87a55dfb1b3a595bd2e81f46bbf0294ef7b3378#diff-b67911656ef5d18c4ae36cb6741b7965R80

i used the fancy cat $^ > $@ makefile syntax lol

@micha: we’re very close to being able building everything with boot

what do you all think about adding something like with-scope to the built-in tasks? https://github.com/boot-clj/boot/compare/boot-builds-boot#diff-0a1425bd66240468daf4c256a411ce75R125

seems like the right ratio between useful & complex

lol sorry for the noise

Someone ideas what could make the build fail here? https://travis-ci.org/boot-clj/boot/builds/87538853

@pandeiro: Hey there, I think I may have found a solution for https://github.com/pandeiro/heroku-buildpack-boot/issues/3

@pandeiro: Although now it fails installing the latest boot.sh. I'll investigate that as well to see if I can get the whole thing to work before I send a pull request.

@jannis: i think this will get easier soon, with the self-downloading uberjar stuff

Ok. I was looking for an easy way to deploy a web app built via boot. I don't even care if it's heroku. Are there other alternatives?

@jannis: digitalocean and uberjar are pretty handy. also dokku could work nicely with boot I guess

i think @alandipert deployed a web app to heroku this morning

@martinklepsch: Dokku would be cool but I'd have to bring my old vServer up to date first, I guess. 😉 And DigitalOcean have no free option. This is just for a small demo project.

@jannis: you can use boot's web and war tasks to make a .war you can easily deploy to heroku

@alandipert: Cool. Are there any instructions on how to do that anywhere?

@jannis: https://github.com/tailrecursion/hoplon-castra-template/blob/master/src/leiningen/new/hoplon_castra/build.boot#L44-L51

@jannis: combine with https://devcenter.heroku.com/articles/war-deployment#deployment-with-the-heroku-toolbelt

i'm going to make a 2.4.0 release unless there are any concerns

@alandipert: Sweet, thanks

@martinklepsch: boot build?

for 2.4 you mean?

@micha: I don’t know why we should hold of stuff. Also smaller changeset will make troubleshooting easier.

yes i do it

but please tell me some ideas why the build fails: https://travis-ci.org/boot-clj/boot/builds/87538853 😄

that's a weird one

i've never seen that before

i assume ti works fine on your own machine?

me neither. build works locally. and aether code is unchanged.

it looks like maybe some kind of java sandboxing in the CI environment maybe?

wait ignore me. seems it must be some issue with my rebasing skills it now fails too for me

@micha: lol. https://github.com/boot-clj/boot/commit/0657eb6449c834fa60a188e873a069ba35cfab43

@micha: it really is the clojure 1.6 > 1.7 update

which version of clojure is having the problem, 1.6?

1.7

I guess the issue is that in aether there is 1.6 with :scope “compile” and in pod its with :scope “provided” — probably compile overrides the provided bit

hold on to your butts

@martinklepsch: can you update homebrew please?

all it should need now is the boot.sh

ugh

deploy failed

ok all good now whew

testing it out

@micha: so did I understand right that the new boot.sh kind of acts like a version manager as well? i.e. I can run any version of boot I want?

yep!

well v 2.0.0 and later

the rc and prerelease versions are not supported because those were crazy

@micha i installed 2.4 and first invocation downloaded stuff

but now it exits with status 254

uh oh

does it print a stack trace or anything?

and what is the command line that fails?

do lein new hoplon app && cd app && boot dev

ah there's a boot.properties in here

@alandipert: it's something in the build.boot

yeah i'm bisecting

it's in the set-env

@micha: ok i think it's related to bringing in versions of clj... boot -d org.clojure/clojure:1.3.0 repl

clojure.lang.ExceptionInfo: loader constraint violation: loader (instance of java/net/URLClassLoader) previously initiated loading for a different type with name "clojure/lang/Compiler$Expr"

what is that

https://github.com/Homebrew/homebrew/pull/45361

it's the hoplon dep

i concur

i wonder if it has something to do with setting the thread context classloader

damn i think maybe that's it

if i set-env from an established repl, it works

https://github.com/boot-clj/boot/blob/master/boot/loader/src/boot/Loader.java#L225

that looks like a possible culprit

@micha: anything that could require a new binary release?

maybe 😕

@micha: I’ll close the homebrew PR for now. let me know when I should reopen

ok thanks @martinklepsch

wow

it appears to work if i add a global (set-env :exclusions '[org.clojure/clojure] ...)

not sure what is going on there