@micha: is the 2.5.0-SNAPSHOT supposed to work from boot.properties?

no i had some issues with clojars

working on it now tho

ah 😛

i corrupted one of the files in the maven repo by trying to deploy from my home connection which is super slow

hahaha oh man, well these things happen 😛

ill wait until tomorrow to test it out

@flyboarder: ok i think we're in business

you can set BOOT_VERSION=2.5.0-SNAPSHOT in your ~/.boot/boot.properties file

and it should download everything and update itself

Nice : Boot @ 36:26 : https://www.youtube.com/watch?v=50vU6rp2jyA (Interactive programming - Daniel Szmulewicz)

@micha: still not working

i think there is a space in the url it is trying to resolve

did you put a space in the boot.properties file?

🙃

yes

that's a bug!

it should trim the values from the properties file

i guess that gets tricky

probably don't want to change the properties file semantic

are you managing the properties yourself or with propertied?

what is propertied?

https://github.com/michaelklishin/propertied

oh, that stuff happens in the java part of boot

https://github.com/boot-clj/boot/blob/master/boot/base/src/main/java/boot/App.java#L172-L186

I know basically no java so I can only kinda read that 😛

shouldnt each property be passed to something that checks it’s of the expected format?

like they are all strings really but this might also be good for the settings which are paths

yeah some validation could be done

@micha: now I know this is a task error but not sure if it means a bug in the option validation that was changed

cli: option notifier: expected optarg, got sym

can you paste the task definition please?

that looks like a legit error

maybe?

https://github.com/jeluard/boot-notify

im just calling notify

yep that's a bug

https://github.com/jeluard/boot-notify/blob/master/src/jeluard/boot_notify.clj#L44-L68

so the --notifier option needs an optarg

i don't think that ever worked

same with the rest of the options, --title, --icon, --pid

like

https://github.com/jeluard/boot-notify/blob/master/src/jeluard/boot_notify.clj#L47

try using those options from the command line with 2.4.2

they won't work

line 47 is ok

the rest are not

hm but it works in 2.4.2 boot file?

try giving the --title option on the command line

with boot 2.4.2

does it work?

BOOT_VERSION=2.4.2 boot notify --title foobar

ah ok

so that fails also

so the new error things are working

so the new validation is correct then?

finding bugs, fixing them

yeah ok ill open an issue on the notifyer task

@micha: im still having the issue where .hl files in a checkout dep are not recompiled

everything else looks good tho! especially the new target task!

oh yeah, it might be overly aggressive caching in boot-hoplon?

i think so

awesome! thanks for testing it out

are you on windows btw?

i havnt tested it on my windows builds yet

but yes i use boot for windows automation

okay cool, hopefully it will work smoothly there too

is there a boot wish list somewhere? i’d really love to help working on clr support

my dream is clojure (boot) on windows without java

that would be awesome yes

a wiki page perhaps?

the groundwork i think has been laid, becaue boot does work with dunaj, which is an alternative to clojure

i guess that's not really helpful

because dunaj runs on the jvm so interop works

we'd need to abstract away the interop parts

which is good practice anyway

yeah i can help with some of the c# interop but I think refactoring the codebase just to abstract the current logic would be the first step instead of trying to do both

yeah

there is a lot of interop in boot for performance

but it's all wrapped in clojure so it's doable

mhm im trying to get through all the java, maybe making boot build with boot will be my next challenge, the multi thing looks promising with the target task now

but first real work 😛

there is a branch curently that almost works

with boot building boot

the problem is that we use AOT (again, perf)

so the classes that are loaded in boot already can't be compiled, because they're already loaded

so we'd need to defer compilation or just forgo AOT

one possible solution would be to have boot compile itself at runtime and cache the class files

like the first time you run boot it compiles its own classes

and thats kinda what I was thinking for the cross platform

first run compiles platform classes

yeah it could choose the implementation based on the platform

that would be good also for binary compatibility, like you could compile for your version of the clr or jvm

that might give some optimization possibilities with newer versions of the platform maybe

currently i compile on java 1.7 for binary compatibility

the compiled classes will still work on 1.8 and 1.9

mhm and allows for wider version testing

boot version 2.5.0 has been released

boot -u to try it out

changelog: https://github.com/boot-clj/boot/blob/2.5.0/CHANGES.md

@micha: and all the others thank you for working on this.

Hi! I'm wondering if I am hitting a boot bug here. My project depends on [circleci/clj-yaml "0.5.5"] and boot builds it into my uberjar - however, it also builds in a different clj-yaml project that my project depended on before. And that last one ends up being used.

As far as I'm aware none of the other dependencies provide the other clj-yaml dependency. But I can't be certain. Is there a way to find out?

@thomas: thanks!

@jannis: can you do boot show -p and look for clj-yaml please?

Will do

that will show you why the selected version was selected

and what other dependencies are trying to bring in other versions

I just wiped the cache etc. and running boot show (not finished) is downloading a clj-yaml-0.4.0.jar, which I think is the thing I depended on before. So it must be used by one of the current dependencies.

yeah the cache shouldn't need to be deleted, but it also doesn't hurt

i think the other clj-yaml is with a different group id, right?

like just [clj-yaml "1.2.3"] vs [circleci/clj-yaml "4.5.6"]

those are two completely different artifacts

so one won't preclude the other

Yeah

you will want to add an :exclusions [clj-yaml] to the dependency that is pulling in clj-yaml

but that might also make that thing broken

so you might want to have both in your uberjar

is there any reason why you don't want to just have both in there?

Because they both use the same clojure namespace (`clj-yaml.core`) (one is a maintained fork of the other) but have incompatible function signatures.

https://gist.github.com/Jannis/f9d2fc2367f73512a934

oh

I see no other clj-yaml in there other than circle/clj-yaml.

that's quite the faux pas

pro tip: don't do that

Of course. I didn't do it

lol i know, just sayin

now you're in dependency hell

Even org.clojure/clojure itself did depend on circleci/clj-yaml in 1.6.0, but... yeah.

Hooray

clojure has dependencies?

i did not know that

I guess so?

[:heavy_check_mark:] org.clojure/clojure
    ✘ 1.7.0-RC1
      weasel
    :heavy_check_mark: 1.7.0
      com.novemberain/pantomime
      com.stuartsierra/component
      org.clojure/clojure
      org.clojure/clojurescript

oh, no that's kind of inverted

Ah

the top level thing is the artifact that's in your project

I was just wondering why it shows up under itself 😉

so your project will have clojure

the lower level things are the dependencies in your build.boot that want to puill in different versions of the top level thing

Riiight

you can see there that weasel wants to pull 1.7.0-RC1 into your project

but you can also see the checked one, which indicates the version that was actually chosen

Yep

and you can see it was chosen because you specified a version of clojure in your build.boot

but also other deps in your build.boot wanted to pull in that same version

I don't see a checked circleci/clj-yaml though, so are all of these indirect/provided dependencies?

like component and clojurescript

the top level things are only contested dependencies

Ah

if there is no conflict then they won't show up there

boot show -d will show the deps tree

that reflects the dep graph that was actually chosen

but not all the other possible graphs

the other possible graphs are shown in boot show -p

so cljs-yaml will show up in boot show -d, but not in boot show -p unless it's a contested version

so in the thing you pasted above

suppose for some reason you wanted to use 1.7.0-RC1

you would look at the show -p output

and add :exclusions [org.clojure/clojure] to the deps under the second level heavy check mark

eg clojurescript, etc

that's not a great example because you directly specified clojure in your build.boot deps

but you get the idea

Yep, cool

there is also a global :exclusions key you can use in the boot env

that will apply it to all your deps

Ok

boot show -p shows that ring-middleware-format uses the old clj-yaml, hence the conflict.

yeah you're in a pickle really

Since I need that depedendency and the two clj-yaml projects occupy the same namespace... is there a way to solve this?

nope

well pods

Ok

that's what pods are for

Well, I could send a pull request to ring-middleware-format...

but this forking practice is a virus

i can't believe they'd do that

they basically checkmated you

Right

I guess there is another way... roll my own fork as a different namespace in my project.

Awesome, right?

yeah that's what i'd do

fork the circleci one and rename the namepsaces or whatever

Yeah

R-m-f should use latest clj-yaml already

@juhoteperi: Oh, the r-m-f version I use is outdated.

You're right, they use circleci's now.

So there we go...

The solution was right there

@juhoteperi: Thanks for pointing it out.

@micha: And thank you for explaining things. I do know boot show now, which is cool.

🍻

...and it works!

@micha: Maybe develop branch for next version and master for fixes to current version?

yeah that's what i was thinking, too

the patch releases could be via pr to master

And new features to develop

and we rebase 2.6.0-SNAPSHOT on master and force push

like when we merge a pr to master

is that a problem for you?

I think just merge would be better

it would ust mean delete branch and re-pull

rebase and force push should only be used for personal branches

and development branch is not such

hm

maybe make a new branch after each rebase

like 2.6.0-SNAPSHOT-0

i think that works in maven

I would prefer just git flow workflow

master and develop branch and merge between them as needed

i'd like to be able to rearrange commits if possible

so we can keep optimal git bisect behavior

and if we need to revert a feature we can do it cleanly

the only problem with the git flow is with bisect and revert

because features are spread across merges and whatnot

Hmhph

Do we even need separate master and development branches?

i made the dev branch for the rebasing

but i'm not married to it

Personal branches are ok for rebasing, but if we start to merge PR's to a branch which is rebased, things start to break easily

yeah i agree there

ok yes

no rebasing

Maybe we just keep merging PRs to master and create branches as needed

yeah that is probably the best option

and we can just deal with reverts and bisects

Separate develop branch is only useful if we wanted to release bug fixes without releasing some new features

But that's not too useful, we can just release bug fixes with next feature release

yeah or make topic branches if we want to make a limited release to see if a feature is good or not

it would be nice to get feedback about new features somehow

before releasing them

it would have been nice to have snapshot deployed earlier this time, maybe

Yeah

so people could be using it

What does this mean? Implicit target dir is deprecated, please use the target task instead.

Just updated to boot 2.50

in the future boot won't automatically write to the target directory

there is now a task for that, target

what will happen if you don't use the target task? Where do the compiled artefacts go?

nowhere!

non capiche

a lot of times you don't care about the target

or the target introduces some issues, like if you run two instances of boot

OK, I'm trying to wrap my head around the implications

Consider this: https://www.refheap.com/112766

This will require a target task to be injected?

yeah if you want the fileset to be dumped into a directory you'd want to use the target task

Will the target task clear the target dir?

(comp
  ...
  (target :dir ["target]))

Would be useful to have a task which copies a single file to given target

yes, we may want to make that an option though, to disable clearing

the sift task is really fast now

Yeah I'll probably use sift to select only the uberjar anyway

with boot 2.5.0, I am seeing this: Caused by: java.lang.ClassNotFoundException: clojure.core.reducers.CollFold

uh oh

there was a ticket about this

https://github.com/boot-clj/boot/issues/258

@danielsz: can you paste stack trace please?

sure

micha, how can I quickly revert to boot 2.4.2 on my production server. Emergency here.

@danielsz: Just edit ~/.boot/boot.properties or set BOOT_VERSION=2.4.2 on shell

or maybe it's ~/.boot/cache/boot.properties nowdays

@juhoteperi: thanks!

@micha: OK, I'm back to safety on the production server. Now I can look at what happened with boot 2.5.0.

http://adzerk.com/blog/2015/12/boot-2.5-released/

@micha: Looks like it's an aot thing. It only happens when I run the uberjar.

http://turquoiseandgold.com/tgblog/wp-content/uploads/2015/04/pop-champagne.jpg

@danielsz: if you can make a repo that demonstrates i can investigate

@micha: I'm continuing the investigation. will update.

@danielsz: i get that error when i try to resolve CollFold without requiring cloujre.core.reducers

perhaps boot versions prior worked because we required reducers somewhere? and your code didn't have to

yeah that's what #258 was about i think

@alandipert: could be. But then it comes from a third party library. I don't use reducers.

I've updated the cider-nrepl. Could be the middleware.

nice writeup @alandipert

thanks! and thank you for your work on the changelog

btw, https://boot-clj.com/ doesn't load w/ SSL

good catch! fixed

@alandipert: @micha Awesome notes for the new release. Congrats! 🍻

@danielsz: thanks! to you to. thanks for all your help

@micha: @alandipert I think the problem was elsewhere. With boot 2.5.0, the build task produces project.jar while before it was producing an artefact named after the project pom. https://www.refheap.com/112766

God, I hate to be the messenger of bad news at a time like this.

I could be missing an important piece, too.

The target task makes sense. I understand the motivation after having read the notes.

The pom task has been extended, but no API breakage. Is order of importance in the build pipeline (https://www.refheap.com/112766 ) that could explain my observation?

It looks like the pom's project name is not being carried over by the uber or jar task.

hey guys! Any ideas what can cause errors like this after upgrading to boot 2.5? http://paste.in.ua/1097/

@micha: This tripped me up: Jar task produces jar with default name (project.jar) when multiple poms are found in the jar and the --file option isn't given.

@micha I have only one pom, but the jar produced is project.jar

@micha: By specifying the filename with -file on the jar task I could get the expected pom project name back.

@danielsz: you're making an uberjar right?

@micha: correct

can you please do this:

jar tf target/project.jar |grep pom.xml

where target/project.jar is your uberjar

to verify that there is only one pom in there

Sure. So there are plenty of poms there.

ah ok

But these are the poms of dependencies

yeah

that was another bugfix

we were removing those by default before

but that interferes with libraries that look for their own pom to know what version they are

ah, I understand

No easy fix then, I guess.

Not a big problem anyway, but a surprise.

maybe changing the default jar exclusions was a bad decision

Another thing I was wondering about: is there a use case for writing the fileset to multiple directories at once, since the :dir option is a set?

(in the target task)

probably not

haha, ok

@micha: i might have to rewrite boot-runit against boot 2.5.0. In particular, the logic that was extracting information from the pom. It was selecting the first pom, since others were excluded. This logic is now broken if I understand correctly.

https://github.com/danielsz/boot-runit/blob/master/src/danielsz/boot_runit.clj#L129

@micha: r will be the url here: https://github.com/boot-clj/boot/blob/master/boot/core/src/boot/task/built_in.clj#L737 and a string can't be merged with the repo-map

@micha: and @alandipert I could confirm that the change in jar exclusions breaks boot-runit. I can't just scan the fileset for a pom.xml and presume it belongs to the project. When building an uberjar, fileset is full of pom.xmls from dependencies.

I can add an option to boot-runit to provide the name of the uberjar, and get rid of the guessing.

Is this what we want?

you could sift out the poms when you make the uberjar

sift --exclude 'pom.xml$'

if you do that before your pom task in the pipeline you won't get any deps poms

before your pom task but after uber of course

the real problem here is that there is no convention for application descriptor files

like artifacts in maven have a pom.xml that provides metadata

but i don't know of any equivalent thing for applications, which is what your uberjar is

perhaps the manifest.mf file

there you go

add metadata to the jar manifest

then your runit task can look at that

@micha Nice idea.