any luck?

well i think i found the problem, sort of

or rather a workaround

@alandipert: can you try that one?

it's bumped to version 2.4.1

i can in a few mins

brb

sweet

i think this fixes it actually

but i'm worried that pod isolation has been compromised somehow

yeah i'm not a fan of the global exclusion

it's not excluding it from the deps

just from the jars that are added to the classloader

clearly clojure is already loaded, so adding the clojure jar again is redundant

but i don't understand why it all of a sudden breaks

if you add like, dunaj tho

it uses BOOT_CLOJURE_NAME

so maybe your BOOT_CLOJURE_NAME is dunaj and a dep brings in clj

if you're using dunaj presumably you'd have an explicit clojure exclusion

true, but this would still be new behavior for you

yeah it would just prevent dunaj from being loaded again

how so?

it only prevents something that's already on the classpath from being loaded again

if BOOT_CLOJURE_NAME is dunaj it wouldn't change anything about clojure deps, i don't think

oh now, but the problem may exhibit itself, no?

oh i suppose it won't be clojure.lang.Compiler$Expr

so it's good-ish

i want to know what is different now

lol

why it break all of a sudden

yeah not cool man

compiled with java 7, right?

yes

i need to do dishes but after that

i can plug in and turbocompute

bump the com truise

ok i'm going to head home

ok later

although i can't deploy from there

should i push 2.4.1 for now?

i'll be able to

oh ok

sweet

if you deploy don't forget to make a release with boot.jar for 2.4.1

doesn't need boot.sh or boot.exe anymore, just boot.jar

from the bin/ dir

a github release i mean

for the download

ok yeah

ok i am ready to compute

me too, finally

i'm trying to get java 7 going

i can only remember how to maintain multiple JDKs on 2 OSes at a time

but i'm on the one that was not cached in my brain

haha

sudo update-alternatives --config java

and also

sudo update-alternatives --config javac

oh yes

i don't know why java and javac are separately configured

but so it goes

all of them are

jar, javap, etc

tons of crap in the jdk bin

i need to learn how to use their tools

the profilers and debugger tools

i recommend https://www.youtube.com/watch?v=S1mzUi_zbEs

the ones that come iwth the jdk are supposed to be good

oh wait, wrong talk i think

i could swear there's another one where he talks about jvm debugging

that one is nice coverage of invokedynamic tho

yeah the invokeDynamic talk is great

graal is still a great name

@martinklepsch: feel free to open that brew PR again at your leisure, 2.4.1 is good

@micha: Should boot.App be available in all pods?

Hmm, I guess the problem is that boot/aether doesn't depend on boot/base

yes

Adding dependency to boot/base (with provided scope) to boot/aether seems to work

I had to remove ~/.boot/boot.properties to get Boot working at all after updating to 2.4.1

And now I'm getting exceptions like: java.lang.NoClassDefFoundError: clojure/lang/AFunction and java.lang.NoClassDefFoundError: clojure/lang/RT

Anyone know what issue this indicates:

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: intern in this context, compiling:(/var/folders/rj/8lnf662s3mlgzv5mcq2r2fnc0000gn/T/boot.user250642385654527633.clj:1:715)

I get it when I run the repl task

@pesterhazy: what version? haven’t seen it before — is there a intern symbol in your build.boot?

is that all you got or are there more lines?

git grep intern has no matches

nothing more in the output

I had this once when there was a mistaken ns declaration.... I think

my.project.foo vs my/project/bar.clj

I see. How about bisecting then?

it's strange

it's now fixed; I looked at the git log and I only see the fixed ns declartion

declaration

I must have made a mistake somewhere

still, that is a strange error

Clojure often behaves weird if there's a (ns) vs filename mismatch

I'll bring it up if I see this again

@pesterhazy: did someone else fix it or what happened that it now works?

Seems to be similar to what @juhoteperi reported but removing boot.properties didn’t change the outcome.

Yeah, removing boot.properties didn't fix that. But before removing it, boot didn't start at all for me.

@juhoteperi: I noticed that when you set BOOT_VERSION to something else then 2.4.1 it just doesn’t do anything — is that what you mean?

@martinklepsch yes

@martinklepsch: no, I "fixed" it

@micha: @alandipert 2.4.{0,1} is really strange to me. We should have tested this more. What do you think about rolling these two commits back and releasing a 2.4.2 with only the stuff before micha’s classloader stuff?

yeah, if I s/2.2.0/2.4.1/ in boot.properties, boot dev just doesn't do anything anymore

or is that not how I update boot?

@pesterhazy: sometimes (as with 2.4.{0,1}) you need to also download a new binary. 2.4.0 was supposed to be the last release that requires a new binary update. 😄

what is the state of 2.4.1? i'm seeing something very weird where it looks like tasks in our CI are running twice per invocation

@pandeiro: with 2.4.1?

Binary is 2.2.0, but it seems to pull in 2.4.1 versions of the libs

do you have a boot.properties file? calling boot -u?

I do, and it specifies BOOT_VERSION=2.2.0

If I specify a boot-core version in build.boot would that prevent Boot from retrieving and using 2.4.1?

@pandeiro: BOOT_VERSION is supposed to handle that, are you sure that env var is properly exported on CI?

@pandeiro: CircleCI? maybe ssh & boot -V could give some hint

@martinklepsch: the boot.properties file is at the project root where boot ... commands are run -- would I need to do something more than that?

I cleared the CircleCI cache, so I assume that is why it is retrieving those latest versions of the libs

But if my :dependencies specify a version of boot, will it peg to that version of boot, pod, aether etc?

(right now I don't specify anything)

@pandeiro: no that sounds right. are you running boot -u?

nope, never

hm. the :dependencies thing should really not be necessary and I’m not sure if it’d help. only thing I can think of for troubleshooting is boot -V

besides that I have no clue why tasks would run twice in 2.2.0 or 2.4.1

@martinklepsch: but the expected behavior of boot is to download the latest versions of the libs if none are present yet in the local maven cache, right?

or the ones specified via BOOT_VERSION. usually your project should not have a dependency on boot. maybe some of your deps imports it?

i'm less worried about the tasks running twice (maybe just outputting twice -- could be a buggy circle ui too) but more about how i can specify and control which boot lib versions are obtained

i don't have any deps that are newer than boot 2.4.1 though...

do any boot (aether/pod/worker/core) deps show up in boot show -d?

nope, none

are you sure BOOT_VERSION=2.2.0 for example means boot binary and libs version 2.2.0? I'm thinking it just means the binary?

no it definitely means libs. can you check boot -V? I’m thinking maybe it just downloads the deps but doesn’t use them? … similar to how boot show -u acts

#
#Tue Oct 27 09:35:47 BRST 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.2.0
#App version: 2.2.0

is that from CI? if so I’m pretty sure no other deps then 2.2.0 are being used. Still weird that it downloads latest though.

no that is local, I'll do it on CI too

what would happen if boot.properties specifies a BOOT_VERSION lower than the version of the binary that was downloaded? Any idea?

binary version can’t be changed via BOOT_VERSION so it would still be whatever version the binary is that you downloaded

so one issue is that a different version was being specified in circle.yml boot install step than in boot.properties...

And it does seem that when those two don't match, it retrieves boot 2.4.1 and I get the double output issue (even with boot -V etc)

that sounds strange what version did you download and which did you specify in boot.properties?

my local version is still 2.2.0; a recent update to our circle stuff made the install retrieve 2.3.0. properties version has always remained 2.2.0.

But don't worry about it @martinklepsch -- I think I'm just having a twilight zone moment here...

Thanks a bunch for sorting me out

Ah I guess the ultimate question: would you recommend upgrading to 2.4.1 right now?

no

Or would it maybe be smarter to wait on the next release?

I’d wait. I’ll try to reproduce your issue and log an issue if I can.

yeah we should roll back

do we have a list of issues with 2.4.1?

a lot of stuff in the scroll buffer

we should establish some testing process to avoid this in the future

definitely

@micha: two things 1) boot $task returns without any output 2) https://github.com/boot-clj/boot/issues/321

@pandeiro: what tasks did you invoke that caused duplicate output? any? even boot -V?

@martinklepsch: yes even boot -V, boot show -d, as well as project-specific tasks

/v/f/s/4/T/boot-test> boot220 -V
#
#Tue Oct 27 12:59:37 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.3.0
#App version: 2.2.0

the combination was: binary 2.3.0 installed; BOOT_VERSION 2.2.0 specified; empty ~/.m2/repository

oh, other way around ;D

@martinklepsch: feel pretty confident now that installing boot and then running a command with an empty maven will cause boot to download the latest version of the lib

do you not see that behavior? is that not the expected behavior?

yeah this is expected behavior, but latest release is bad

Additionally, I'm getting The command '/bin/sh -c boot -vv' returned a non-zero code: 254 in Docker Hub and Travis builds that bring in 2.4.1

@micha: Do you know what 254 means?

maybe since i'm trying to publish a 2.3.0 image, I could change that step to boot -d boot:2.3.0 -vv... I wonder if that would work

I’m confused:

~/c/d/boot-test2 rm -rf ~/.m2/repository/boot/
~/c/d/boot-test2 boot230 -V
#
#Tue Oct 27 13:21:33 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.2.0
#App version: 2.3.0
~/c/d/boot-test2 boot230 show -d
Retrieving pod-2.2.0.jar from 
Retrieving core-2.2.0.jar from 
Retrieving worker-2.2.0.jar from 

Huh, why is it not retrieving boot itself?

I get "Retrieving boot-2.4.1.jar from ..." and then the additional deps are 2.2.0 as well, like yours

Ah maybe the boot lib is not cached in .m2

@pandeiro: afaik boot-x.x.x.jar is just to get some sort of fake clojars transaction

Hmm, my boot -d boot:2.3.0 -vv idea above didn't work... It still gets 2.4.1 versions

it’s what the binary checks for new releases and during deploy it’s uploaded after all other jars

The scenario I mentioned above (binary 2.3.0, version 2.2.0, empty cache) produced this:

$ ./bin/circleci-deps
Retrieving boot-2.4.1.jar from 
Retrieving clojure-1.7.0.jar from 
Retrieving dynapath-0.2.3.jar from 
Retrieving pod-2.2.0.jar from 
Retrieving shimdandy-impl-1.1.0.jar from 
Retrieving core-2.2.0.jar from 
Retrieving aether-2.2.0.jar from 
Retrieving worker-2.2.0.jar from 
Retrieving parsley-0.9.3.jar from 
Retrieving regex-1.1.0.jar from 
Retrieving reply-0.3.5.jar from 
Retrieving cd-client-0.3.6.jar from 
Retrieving clj-http-lite-0.2.0.jar from 
Retrieving slingshot-0.10.3.jar from 
Retrieving clj-stacktrace-0.2.7.jar from 
Retrieving drawbridge-0.0.6.jar from 
...

Note the boot version and the pod, aether, etc versions

@micha: as for rolling back I made a test with all commits until the new binary stuff and that seemed to work fine

I just followed https://github.com/boot-clj/boot/wiki/Cider-REPL and get a stacktrace when running boot repl Is that a known issue?

clojure.lang.ExceptionInfo: java.lang.NoClassDefFoundError: clojure/lang/RT, compiling:(deps/toolsreader/v0v9v2/clojure/tools/reader/impl/utils.clj:1:1)

@ska: it is, and it's new... we pushed a broken release last night

to fix you can export BOOT_VERSION=2.3.0 and download https://github.com/boot-clj/boot/releases/download/2.3.0/boot.sh

Heh, just the day I decided to give boot a try 😉. No worries. Anything I can do to help?

perfect timing 😉

@ska hey and welcome 😉

@martinklepsch: it's about time I join, eh?

i'm gonna update the README with 2.3.0 links

until we get this sorted

@ska: true words. anything specific you want to use boot for?

@martinklepsch: First, I love the claim. Second, just want to generally be informed. So, no, nothing special. Will try to compile mixed clj and java project.

@ska: that will be a breeze, just did that the other day

Nice, setting ENV BOOT_VERSION 2.3.0 in my boot 2.3.0 Dockerfile got it building fine. Works for me. I guess hard-coding that in is probably better any way? Thoughts?

yeah always pin versions in unattended deploys

@martinklepsch: hmm, breeze? Now boot fails silently with return code 254 😕

Need to find out what I am messing up

@ska: did you downgrade to 2.3.0?

yep and boot repl outside of the project dir gives a REPL

do you have a boot.properties file in the project dir?

Uhm, I had a REPL a few minutes ago in /tmp now it is not working anymore. So, not project related

Ah, different shell. Over there, I already had exported export BOOT_VERSION=2.3.0

@ska did you download the 2.3.0 binary as well?

I did, yes. Now I also removed ~/.boot/cache

OK, works in project

How do I add java source paths?

ok i think i have a fix

uploading

@ska: you just add them like any other source path, i.e (set-env! :source-paths #{“com/main/bla/src”})

@ska: there’s a javac task (`boot javac -h`) that can compile them for you.

basically you’ll want a combination of pom, javac and jar — maybe aot as well

@micha: why do we only want a partial revert?

it's just the loader

2.4.1 is ok

I’d have thought we fully revert the change and continue in another branch with testing

well we can't remove 2.4.1 from clojars

so that will remain an issue

we can still do the other thing but this at least fixes that problem

@micha: so you mean a new binary would fix it and the libs are ok?

all i'm doing is uploading boot.sh and boot.exe to github releases

yes

my internet is slow so it's taking a minute

so we have a 2.4.2 or do we just override the binaries?

there were no binaries in that release

only boot.jar

so it's good

ahhhh!

got it

building and testing now

i think we need @tcrawley to consult with the loader

haha, I thought of him as well

i'm doing something wrong with the classloader loading

i dunno man it looks legit

dotted i's, crossed t's

Can I reload build.bootwhen I am in the boot.repl?

(load-file "build.boot") @ska

@micha: no problems with side-effects like set-env! then?

well stateful things can cause problems with reloading

but that's always the case

set-env! should be okay though

judicious use of defonce can help with those kinds of things if you run into issues

Ah, interactive build-script development. Joy!

:thumbsup:

And C-c C-k from Emacs works, too. 😄

@martinklepsch: https://github.com/boot-clj/boot/releases/tag/2.4.1

boot.sh is uploaded

@micha: sweet. indeed fixes https://github.com/boot-clj/boot/issues/321

@micha: btw, do things in boot.properties override env vars?

Ugh, missed a meeting while playing around with boot.

haha

what is the supposed way of mimicking gradle wrapper? Check in boot.sh?

dunno about gradle wrapper, sorry

https://docs.gradle.org/current/userguide/gradle_wrapper.html

A thin wrapper supposed to be checked in. Eases installation pain and makes builds reproducible.

@micha: sup? anything I can help with?

@ska: https://github.com/boot-clj/boot/issues/163 — I think now that parts of #300 have been reverted it’s not yet there. Wont be long though I guess

^^ this seems to fix the problem with the loader

@martinklepsch: Yeah, I read that earlier. That was the reason for me asking, if boot.sh (the Loader) should be checked in now.

@ska: you could check it in. I think the point of #317 is that the binary does not change at all anymore

@micha: what do you think about depending on 1.7 for all the libs? for some reason I can’t get this to build without it: https://github.com/boot-clj/boot/pull/318/files causing weird things:

java.lang.IllegalAccessError: tried to access method clojure.lang.RT.classForNameNonLoading(Ljava/lang/String;)Ljava/lang/Class; from class boot.from.digest$loading__5340__auto____25, compiling:(web.clj:1:1)

i dunno, how many people are using boot with 1.6?

I would think not a lot but well… trying one more thing.

ok i thnk this fixes the issues

can we test?

will in a sec

it should work with the 2.4.1 lib in clojars

@micha: one more thing worked ^

@micha how much did you sleep tonight? 😄

@martinklepsch: i'm down with splitting boot.tmpdir into a separate library btw

we'd need to keep the same namespace names of course

@micha: I was thinking the registry stuff could go in there too but fine too if not

yeah that's a separate thing, i think

ok i'm going to update the boot.sh and boot.exe files in the 2.4.0 release

since those are fubar anyway

can't hurt

Is there any work done on https://github.com/adzerk-oss/boot-test/issues/9? I'd love to be able to use the junit formatter.

my thought was the fileset requires something like tmpregistry in most cases anyways

that's true, but the directories could come from anywhere

might make sense to separate those concerns

we should make a TmpRepo type

a mutable java type

that can hold the mutable state

or amybe just an atom i guess

@micha: with new binary App Version will always be $BOOT_VERSION is that right?

yes

unless you're using an older version of boot

which will also work

“of boot” as in boot binary right?

BOOT_VERSION=2.1.2 for example

that will be using app version 2.0.0 and lib evrsion 2.1.2

or something like that

but 2.4.0 and later will have app and lib versions the same

https://github.com/boot-clj/boot/releases/download/2.4.0/boot.sh

should be a-ok now

k, then everything seems to work fine 👍 nice one!

i'll remove the boot.sh and boot.exe from 2.4.1 release when we are confident the issues are resolved

👍

and point the README at the 2.4.0 .sh and .exe

are these the old ones?

no they're the new ones

i replaced them

i like having the binaries on the 2.4.0 release because that's where the new regime comes into effect

the commit message for 2.4.0 explains all about the new loader and whatnot

cool, muddling with releases seems like something we’d want to avoid but in this case

i guess it's possible that the bad versions could be cached somewhere

lol that emoji is incredible

I wouldn’t be surprised, there have been previous occasions where people got old binaries somehow

when you feel confident about the loader can you PR to homebrew please?

i'm going to update the README to point to the 2.4.0 binaries now

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

@tcrawley: thanks for offering your help, I think micha worked it out now: https://github.com/boot-clj/boot/commit/383d282b9858d21e1cfd9e25c88b610009df4615

@tcrawley: good morning

i was creating a new URLClassLoader instance, loading the uberjar (the one with shimdandy) into it, setting it as TCCL, and then calling boot.App/-main in there via reflection

that seems to interfere with the clojure shim

the fix was using reflection to add the uberjar to the system classloader by exposing the protected add-URL() method via reflection

and not creating a new classloader

i don't really understand the problem, but it seems to work (tm)

i think maybe shimdandy needs to be at the top of the classloader hierarchy

@micha: i still get the problem with cider using the new boot.sh

ugh

what is the exception?

oh, wait1

i will run this thing in docker to make sure

the cider thing works for me

yeah i think i was confus

i rm -rf /.m2/repository/boot and /.boot thoug

@micha: ah, the issue may be that the shim resets the TCCL to its own CL, so the CL you set as the TCCL would be overwritten?

that sounds like it

hm

calling the -main method in the uberjar is in "tail position" though

the loader doesn't do anything after that

doesn't need to load any classes or anything

classloaders are so mysterious

if you understand them you're like a shaman

does that uberjar have clojure in it?

nope

it's the old binary

the java program that loads the shimdandy api

and then starts clojure in shims

and the shims can't find clojure.lang.RT at that point?

the first issue was loader problem where it tried to load clojure classes more than once

@micha: ok i can confirm, it works - totally clean with just the offending ~/.boot/profile.boot

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"

we fixed that in boot clojure code to filter out org.clojure/clojure from being added dynamically via set-env!

since it alerady is loaded

but that was a red herring i think

i think the real problem was pod isolation somehow compromised

because after that was fixed more subtle issues arose, like this one https://github.com/boot-clj/boot/issues/320

what are you setting the parent loader to for the CL you are giving to the shim?

i tried setting it to TCCL, system classloader, and Loader.class.getClassLoader()

none of those made any difference as far as i could tell

the current thing that seems to work is to mutate the system classloader in place

via reflection, exposing addURL()

instead of creating a new URLClassLoader and loading the jar in that

so i get a handle on addURL() for the system cl, make it accessible, then add the app uberjar to it, and call -main via reflection

appears to solve the problem

I'm glad that works. I'm just trying to figure out the cause, since I don't know what's going on either :)

i was thinking maybe shimdandy api needs to be at the tip of the classloader hierarchy?

maybe, but I don't know why that would be the case

hmm, the two places I've used it, it wasn't, so I don't know

oh interesting

you are loading shimdandy into a lower level classloader, at runtime?

like in immutant?

yeah, in immutant 1.x and Vert.x, it was loaded dynamically, at runtime

i am going to build a sweat lodge

and make a classloader symposium

heh

we can take peyote and learn about classloaders

that's probably the only way to find the truth

it came to me in a dream

like watson and crick

I've got to go work on something else now, but will let this stew in the back of my head and see if I can figure it out

awesome, thanks!

let me know if i can help in any way

everything seems fine now with boot

my pleasure! will do, and feel free to ping me any time with stuff like this, even if I usually don't have an answer :)

fortunately you usually do have an answer 🙌

you have the worst library to support, because people must come to you with the worst problems

"why don't my crazy classloader shenanigans work?"

heh

Does this look like a sane way to set dependencies at task runtime?

sure, although it doesn't actually change the dependencies loaded in the jvm

so if you have conflicts it won't help with that

but it will change the dependencies for the pom task, which is what you want there i think

by "the jvm" i mean the build process runtime

well if it does not actually change the dependencies then aot will break

or not?

yeah so you can't use :all there i guess

there could be weird effects with aot, i'm not sure

The reason I’m exploring this is because when one build needs the jar of another one that hasn’t been built yet it will fail

yeah

i was thinking about that

i want to try the runBoot() method

you can make it so that the output of one build is the input for the other

and set a watcher on that

so the builds will cascade

like the build that makes the jar emits the jar to some target dir

which is the source-paths of the other build

so the watcher will pick up the change

with runBoot() you have isolated builds

in separate pods

so no aot issues

basically you're running boot in boot there

that sounds very much like how you’d orchestrate lein building interdependent things 😄

yeah

i think step 1 is just to continue to use the makefile, but have it call boot in each module instead of lein

when that's working and producing correct jars we can make a build.boot in the main dir that calls runBoot() on all of those

all in one process

and we can set up the targets and source-paths so they will all build correctly

eliminating the need for make's dependency tracking

yes i thnk that's the way to do it

LCFDI

ok since it looks like the world is no longer on fire i will start my day

alternatively to multiple runBoot couldn’t we just use pods and pass them the fileset?

when I set BOOT_VERSION to a development build I just made on my machine I get errors that boot.jar can’t be downloaded from github

is there way to completely blow away boot from an OS X system and reinstall it from scratch?

@peterbak: delete the binary + rm -rf ~/.m2/repository/boot

martinklepsch: the makefile has a fix in there

to install the boot.jar in the right place

are you using the makefile?

or the boot-built-with-boot?

both right now

trying integrating boot into Makefile as you said, then we can merge and improve from there

thanks @martinklepsch trying that now

it won't try to download it if it's installed in BOOT_HOME/cache/bin/BOOT_VERSION/boot.jar

the makefile should do that for you

ok

i thnk runBoot() would be much simpler

because you don't need to mock anything up

we can build a gulp-like library on that

to handle the interproject dependencies in a nice way

because with multiple projects you don't want a pipeline anymore

you really want a dependency graph

which is what you don't want for a single project

lol, how can I have a symbol ’boot in my build.boot? > boot already refers to: #'boot.core/boot in namespace: boot.user

boot.core/boot is a crucial function

you don't want to replace that guy

but if you really want to you can do alter-var-root on it

I know but how can I pass ’boot to the pom task then?

and replace it with another thing

why would you do that?

to build the boot project?

you're getting the error because you're defining a function or defing a var named boot

which you shouldn't do, just name it something else

argh damn, sorry 😄

I forgot my task was also named boot 😛

:thumbsup: no worries!

i'll make a demo of what i mean today

a multi-module build

with watcher support

cool, I’ll integrate the thing I have with the make file now

sweet

this may be a bit trollish but why isn't boot self-hosting?

@chrisn it will be soon

Ah, the joy of side effects... I added a dir to resource paths once to get a file into an uberjar, then wanted to get that file out of it again, but it still turned up. After a short detour searching for a clean task, I found that the set-env! was still in effect, because I did not set it back.

Uh, wait. The file is still there

Hm, what am I missing? A file was copied to the target-folder because I had a directory in the :resource-paths. I remove that setting from the call to set-env! and manually (set-env :resource-paths #{}). But the file is still in target and gets added to the uberjar.

s/set-env/set-env!/

@ska: you can't un-add resources from the classpath, but you can filter them from the fileset

not being able to remove from the classpath is a jvm limitation we can't work around

we mitigate by making it possible/easy to create new classpaths, aka pods

so what you want is to filter from the fileset, this is the set of things that will show up in target. you can check out the sift task

you can use it to filter out items in the fileset by regex

if you look around the build.boots for cljsjs packages, you can see many usages https://github.com/cljsjs/packages

on those rare cases I can also restart the JVM. Would that help? Would that remove the file from target dir?

it will reset the fileset which will probably lead to the result you want

@ska i think (set-env! :resource-paths #{}) should work

are you sure the file isn't getting in there some other way?

also removing a directory won't trigger the watch task, so maybe you need to manually trigger a build

by touching a file or something

> i dunno, how many people are using boot with 1.6? we actually had to lock down one of our components to 1.6 because it was failing with some weird exception, iirc but otherwise are on 1.7 everywhere else

we are rewriting that component in the coming days anyway though...

I think it would be best to keep 1.6 compatibility at least until 1.8 is released

yeah, also in boot we can do whatever needs 1.7 in the worker pod

Should 2.4.1 be working now?

and have the worker pod use 1.7

@juhoteperi: yep!

if you download boot.sh from the 2.4.0 release on github

Okay, started working after redownloading it

yeah the original one had a bug

!m @juhoteperi

🐝

Can't wait to try out the next release packed with goodies.

@micha: regarding the files which end up in the JAR or not.... I need to play with it some more. Will come back if I think something is not as it should be.

Just sent a PR to boot-test adding junit formatter support. Feedback welcome https://github.com/adzerk-oss/boot-test/pull/11

checking the build error... not sure yet if it failed because of the failing test (that I put there on purpose) or something else

It's at least using historical version of boot, pre 2.0 release

Oh, right. Will check that too

Updating .travis.yml should help and would also be good idea to update the dependency in build.boot

cool, will do both

@nberger: Also, 2.4.1 would probably be preferred as 2.4.0 is quite broken

Oh thx, I thought 2.4.1 was the broke one 😕

I ended sending a separate PR to update boot to 2.4.1

how can i get the built-in boot web task to reload its serve function when code is changed?

@esp1: the web task only makes a web.xml and injects some java, it doesn't start any servers... what are you trying to do?

oh ok - i was trying to use tailrecursion/boot-jetty to serve a clojure backend

as per https://github.com/tailrecursion/boot-jetty

oh ok - yeah that task is handy if you're deploying as a WAR file and want to run a war locally

another option that doesn't imply the web task is https://github.com/pandeiro/boot-http

i tried that too - for some reason reloading isn’t working for me with either one

is there an example w/server handler reloading working somewhere?

@alandipert: oops, seems like boot.sh is not available for download in the 2.4.1 release, so the boot-test build is still failing 😕

@nberger: i'll fix

@alandipert: cool, thx

thx btw

@nberger: would you mind outputting the junit reports to the fileset instead?

at least, that seems more future proof... subsequent tasks could process the xml and do things with it

@alandipert: Yes, sounds like a good idea, I'll try to do that.

thanks!

hello guys, if I do boot -h in a Mac machine I don't see any output

what can it be?

@richiardiandrea: what’s the output of boot -V?

try rm -rf ~/.boot/cache/bin

boot -V
#
#Tue Oct 27 20:46:26 CET 2015
BOOT_CLOJURE_VERSION=1.6.0
BOOT_VERSION=2.4.1
#App version: 2.0.0

oh. you need to download the latest executable boot.sh: https://github.com/boot-clj/boot/releases/tag/2.4.0

ah, I installed it with brew

brew is evil

lol ok

brew PR is outstanding but if you want to stick with brew you can set $BOOT_VERSION to 2.2.0 or so and upgrade boot via brew

2.0.0 is pretty old but I think 2.2.0 or so should be on homebrew

that's good then, will try now

no atm is 2.0.0

but whatever works 😄

I see a boot 2.2.0 in homebrew — maybe you need to update brew itself?

like brew update I mean..

uhm

ok i am trying without brew, it feels safer

i downloaded boot.sh and copied in /usr/local/bin and it downloads the right jar

but still nothing

#
#Tue Oct 27 20:56:25 CET 2015
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_VERSION=2.4.1
BOOT_CLOJURE_VERSION=1.6.0
#App version: 2.4.1

does it require 1.7 ?

and how to update it?

shall I dowload in .m2 clojure 1.7 ?

@richiardiandrea: you can edit ~/.boot/boot.properties

@richiardiandrea: what is the result of echo $? after you run boot -h and it returns nothing?

254

on boot repl as well, same return value from the script

can you once again do rm -rf ~/.boot/cache/bin please?

ok by changing version in ~/.boot/boot.properties it works

@richiardiandrea: what version did you change? clojure?

yep

i am reverting to 1.6 and try your stuff

cleared cache and return of it is again 254

i am going to keep 1.7 for now then

can reproduce, thanks @richiardiandrea!

great! if you want I can open an issue

yep exactly

hi. i’ve just upgraded boot to 2.4.1 and seems like it totally stopped working (eg. boot repl does completely nothing). any ideat wha happened?

@michal: boot -V please

@alandipert: i found my issue with reloading. i had relocated my source into a dir named “client/src/clj”. it looks like reload only works for source dirs that start with “src/"

#
#Tue Oct 27 21:12:34 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.4.1
#App version: 2.0.0

@esp1: ah! i feel like i've run into that before myself and never figured it out

@michal: your binary is outdated, how did you install boot? (you can download the new binary from https://github.com/boot-clj/boot/releases/tag/2.4.0

i took boot.sh from https://github.com/boot-clj/boot#install

a few minutes ago

@alandipert: is this a bug in boot-http? or boot?

@michal: that is strange the checksum should be 9dd9f0ae594b1658fe79477ceb492289, maybe check that?

@esp1: boot-http. https://github.com/pandeiro/boot-http/blob/master/src/pandeiro/boot_http/impl.clj#L66 https://ring-clojure.github.io/ring/ring.middleware.reload.html

@richiardiandrea: can you paste the output of md5sum of your boot.sh file?

@esp1: Wrap-reload defaults to src. Boot-http should pass in options: {:dirs (boot/get-env :directories)\

@richiardiandrea:

barp $ md5sum ~/bin/boot
9dd9f0ae594b1658fe79477ceb492289  /home/micha/bin/boot

yup, checksum is identical:

MD5 (/usr/local/bin/boot) = 9dd9f0ae594b1658fe79477ceb492289

@juhoteperi: cool. do you want to post the pull request or should i?

@esp1: You are welcome to do it. I have enough to do already .)

@michal, hm. only idea I now have is the boot you’re calling is not /usr/local/bin/boot

@martinklepsch: ok, i will try to download it again. give me a sec.

@michal: you already have the right file as far as I can see

@michal I assume which boot = /usr/local/bin/boot ?

@esp1: Note: wrap-reload is used inside a pod where boot.core is not available, you need to call get-env in the task and pass the value to boot-http.impl/server call.

~ % md5 /usr/local/bin/boot
MD5 (/usr/local/bin/boot) = 9dd9f0ae594b1658fe79477ceb492289
~ % /usr/local/bin/boot repl
~ %

@juhoteperi: good call, thx

does boot have any verbose mode to see what’s happening in the background ?

it quits surprisingly fast

@michal: did you try rm -rf $BOOT_HOME/cache?

nope. i’ll do that.

assuming you have BOOT_HOME set

default is ~/.boot

~ % rm -rf ~/.boot/cache
~ % /usr/local/bin/boot repl
Downloading .
~ %

yes, i have a .boot set correctly

ok that looks fine

your BOOT_VERSION must be set to something older than 2.2.0

you mean env variable?

~ % echo $BOOT_VERSION

i didn’t set it by my self

you must have a boot.properties file then

in CWD, or in BOOT_HOME

and in that properties file you must be setting the BOOT_VERSION

@micha: but wouldn’t that be shown when he runs boot -V?

as far as I remember I have a profile.boot only but i’ll double check

yes

you can see it in boot -V

#
#Tue Oct 27 21:12:34 CET 2015
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.4.1
#App version: 2.0.0

^ This is what @michal posted earlier

yup, that’s correct

wat

+1

ok, I have a boot.properties in .boot/

#
#Sun May 24 21:19:58 CEST 2015
BOOT_CLOJURE_VERSION=1.7.0-beta3
BOOT_VERSION=2.0.0

phew 😄

you can update that guy iwth boot -u

i don’t even remember i was placing something like this there

sure

but anyway that should work, i think

@micha: bug, that it prints the wrong BOOT_VERSION in boot -V?

martinklepsch: that bug only affects people who have an old version of boot.sh

and they do boot -u

guys, you saved my evening. repl works now perfectly

martinklepsch: disregard that, i misunderstood your last statement

thanks!

@juhoteperi: i submitted the pull request but looks like it failed ci. error 254 looks suspiciously like the boot version issue above. https://github.com/pandeiro/boot-http/pull/27

@esp1: Updating version of boot.sh in .travis.yml would probably help

@juhoteperi: done. ci passed cleanly this time. i added a boot.properties file as well to pin the version. thx!

^ if anyone could checkout that branch and run boot base —uberjar that would be great, there’s a magic jar file appearing!

@juhoteperi: do you think changelog should be updated for 2.4.1 & 2.4.2 as well? guess it should?

ah yeah

@micha: do you want to update for 2.4.2? not sure I could describe what was done

ok sure

i just made sure that the error gets printed and flushed before the process exists

*exits