This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-16
Channels
- # admin-announcements (44)
- # adventofcode (2)
- # avi (1)
- # beginners (22)
- # boot (328)
- # cider (1)
- # cljs-dev (6)
- # cljsrn (29)
- # clojure (164)
- # clojure-chicago (1)
- # clojure-dev (7)
- # clojure-nl (5)
- # clojure-russia (73)
- # clojure-seattle (1)
- # clojure-turkiye (2)
- # clojured (1)
- # clojurescript (98)
- # core-async (6)
- # cursive (26)
- # datomic (9)
- # editors (5)
- # emacs (41)
- # events (3)
- # garden (2)
- # hoplon (125)
- # ldnclj (18)
- # om (178)
- # omnext (8)
- # onyx (5)
- # parinfer (1)
- # proton (5)
- # re-frame (20)
@micha: is the 2.5.0-SNAPSHOT supposed to work from boot.properties?
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
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
are you managing the properties yourself or with propertied?
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
@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
im just calling notify
https://github.com/jeluard/boot-notify/blob/master/src/jeluard/boot_notify.clj#L44-L68
https://github.com/jeluard/boot-notify/blob/master/src/jeluard/boot_notify.clj#L47
hm but it works in 2.4.2 boot file?
ah ok
so that fails also
so the new validation is correct then?
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!
i think so
i havnt tested it on my windows builds yet
but yes i use boot for windows automation
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
the groundwork i think has been laid, becaue boot does work with dunaj, which is an alternative to clojure
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
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 π
so the classes that are loaded in boot already can't be compiled, because they're already loaded
one possible solution would be to have boot compile itself at runtime and cache the class files
and thats kinda what I was thinking for the cross platform
first run compiles platform classes
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
mhm and allows for wider version testing
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?
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.
you will want to add an :exclusions [clj-yaml]
to the dependency that is pulling in clj-yaml
Because they both use the same clojure namespace (`clj-yaml.core`) (one is a maintained fork of the other) but have incompatible function signatures.
Even org.clojure/clojure itself did depend on circleci/clj-yaml
in 1.6.0, but... yeah.
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
the lower level things are the dependencies in your build.boot that want to puill in different versions of the top level thing
but you can also see the checked one, which indicates the version that was actually chosen
and you can see it was chosen because you specified a version of clojure in your build.boot
I don't see a checked circleci/clj-yaml
though, so are all of these indirect/provided dependencies?
so cljs-yaml will show up in boot show -d
, but not in boot show -p
unless it's a contested version
and add :exclusions [org.clojure/clojure]
to the deps under the second level heavy check mark
that's not a great example because you directly specified clojure in your build.boot deps
boot show -p
shows that ring-middleware-format
uses the old clj-yaml
, hence the conflict.
Since I need that depedendency and the two clj-yaml
projects occupy the same namespace... is there a way to solve this?
I guess there is another way... roll my own fork as a different namespace in my project.
R-m-f should use latest clj-yaml already
@juhoteperi: Oh, the r-m-f version I use is outdated.
@juhoteperi: Thanks for pointing it out.
@micha: Maybe develop branch for next version and master for fixes to current version?
And new features to develop
I think just merge would be better
rebase and force push should only be used for personal branches
and development branch is not such
I would prefer just git flow workflow
master and develop branch and merge between them as needed
Hmhph
Do we even need separate master and development branches?
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
Maybe we just keep merging PRs to master and create branches as needed
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
What does this mean? Implicit target dir is deprecated, please use the target task instead.
what will happen if you don't use the target task? Where do the compiled artefacts go?
Consider this: https://www.refheap.com/112766
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?
Would be useful to have a task which copies a single file to given target
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
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.
@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
@alandipert: could be. But then it comes from a third party library. I don't use reducers.
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
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: By specifying the filename with -file on the jar task I could get the expected pom project name back.
but that interferes with libraries that look for their own pom to know what version they are
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?
@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.
@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.